From nobody Thu Dec 10 10:40: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 5724C1ACCF5 for ; Thu, 10 Dec 2015 10:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wi1-xIDYh0DG for ; Thu, 10 Dec 2015 10:40:06 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 810CC1AC435 for ; Thu, 10 Dec 2015 10:40:06 -0800 (PST) Received: from 88.sub-70-196-16.myvzw.com ([70.196.16.88]:12042 helo=[192.168.43.50]) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1a768H-002P7I-Nu for modern@ietf.org; Thu, 10 Dec 2015 10:40:06 -0800 To: modern@ietf.org References: <56465BCD.1090602@usdonovans.com> From: Steve Donovan Message-ID: <5669C701.3060604@usdonovans.com> Date: Thu, 10 Dec 2015 12:40:01 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <56465BCD.1090602@usdonovans.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Archived-At: Subject: Re: [Modern] Problem statement draft as working group document X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, 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, 10 Dec 2015 18:40:08 -0000 There has been no response to this so I'm going to suggest we put a deadline on opinions. Please express your opinion on making draft-peterson-modern-problems-02 a working group document before Thursday, December 17th. It is important that anyone who supports the promotion of the document also express their opinion. Thanks, Steve On 11/13/15 3:53 PM, Steve Donovan wrote: > All, > > During the IETF94 MODERN WG meeting there was consensus that > draft-peterson-modern-problems-02 be accepted as a working group > document. This would be to address the architecture Architecture > Overview milestone. > > It was recognized that it is not in final form but would be a good > starting point for the architecture overview. > > Please comment on whether or not this should become a working group > document. > > Regards, > > Steve > > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Thu Dec 10 17:05: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 BB81F1B3321 for ; Thu, 10 Dec 2015 17:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.688 X-Spam-Level: * X-Spam-Status: No, score=1.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LA7NNh_6T7N for ; Thu, 10 Dec 2015 17:05:06 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0D491B2BFB for ; Thu, 10 Dec 2015 17:05:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=mww1IICWDKhdOJ3GuFmTjnWvtEMNW3tOaLY1D5jKMDg=; b=kO/kAeFeKSRHKbtr0FcK8FmXkBSHJ/MIHMBUTJSY4HJl0s8N00296aSjd0+/Zu04PxKY2J5ChzsG7G+4CtfwiEnSbX4Xz98OpGe21A/p/nmySnHebGdRJo1cw346m+guOlmF8eF3rwkv1f+OgRb8OK1F1brjXolYRyapRla7iRg=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:53682 helo=[192.168.15.111]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1a7C8u-0002Jd-DQ for modern@ietf.org; Thu, 10 Dec 2015 17:05:05 -0800 Content-Type: multipart/signed; boundary="Apple-Mail=_2B74C35E-6CDA-4728-AE91-9F51A1EF579D"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Pgp-Agent: GPGMail 2.6b2 From: Eric Burger In-Reply-To: <5669C701.3060604@usdonovans.com> Date: Thu, 10 Dec 2015 20:05:02 -0500 Message-Id: References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> To: modern@ietf.org X-Mailer: Apple Mail (2.3096.5) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Modern] Problem statement draft as working group document X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, 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, 11 Dec 2015 01:05:07 -0000 --Apple-Mail=_2B74C35E-6CDA-4728-AE91-9F51A1EF579D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Nah. :-) > On Dec 10, 2015, at 1:40 PM, Steve Donovan = wrote: >=20 > There has been no response to this so I'm going to suggest we put a = deadline on opinions. >=20 > Please express your opinion on making = draft-peterson-modern-problems-02 a working group document before = Thursday, December 17th. >=20 > It is important that anyone who supports the promotion of the document = also express their opinion. >=20 > Thanks, >=20 > Steve >=20 > On 11/13/15 3:53 PM, Steve Donovan wrote: >> All, >>=20 >> During the IETF94 MODERN WG meeting there was consensus that = draft-peterson-modern-problems-02 be accepted as a working group = document. This would be to address the architecture Architecture = Overview milestone. >>=20 >> It was recognized that it is not in final form but would be a good = starting point for the architecture overview. >>=20 >> Please comment on whether or not this should become a working group = document. >>=20 >> Regards, >>=20 >> Steve >>=20 >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern --Apple-Mail=_2B74C35E-6CDA-4728-AE91-9F51A1EF579D 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 iQIcBAEBCAAGBQJWaiE+AAoJEORoZaSQsc1IKGgQALC/5ozlEA+pHfWIUokhU35B cfSE8UcrjC72FcmhI8+dofQBo8yev64qV52UXSSKazLLbXZir2VPi+W+XswdrLoG o5VppQvyFH0l+DiI/H1R0+jyKKyZwWidr/vWSO2zyRqcFEqneAKWC6Z/AUUIuCG6 bUprD0G3Y+0pGbur0oRZfSpn+fIpADLYVHqpkNOdhzYuVpsvKOK2RoBuL727x7XR BQBzfzEgy+vvq95QDRtvxGq3VWrUMEZOjobayP3nOJQG8sALq7K5eX3KUNN5BgKS 2FzchhSgjSyBfaGj/vFdfA1DKcChIXBXMlCB4mzII5ra4EY/YbyAFhdxs8QFJc+C cMwnoaS3U7e2B2hRTPL7Tf3qvrRsaIP7uJBL1PEdolGaaZ+m5PFLYmUAdup0f73G +ZP9LJmCBphmCfDZpyk6efjcvJCxC7TrBI3MB5YdzZhvNSpWRyNDbcE24GyiRPmK rCJtqkM5RCSl6YAl70PPwFW0KOFCZNrzQzdTHiuxxxTZuTYmQ1E4PQ6UupZU5BCS YzZowhWAfF38N/veF5CS+tpKJVX1X/XRm1ltEJcZ379Xac8qK6ttmzmoplU7om7p zK/nDADaPhu3btGrLNz56Ksy+8ZFV7O3h2iltPvr0LfojS+yKI9wEK3UYnYI0En8 CCTg4Kj9l752pceivJYG =ctQ3 -----END PGP SIGNATURE----- --Apple-Mail=_2B74C35E-6CDA-4728-AE91-9F51A1EF579D-- From nobody Sat Dec 12 12:54:24 2015 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF401A9031 for ; Sat, 12 Dec 2015 12:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyOoT1XNGMDt for ; Sat, 12 Dec 2015 12:54:22 -0800 (PST) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id D7AE21A902D for ; Sat, 12 Dec 2015 12:54:21 -0800 (PST) Received: (qmail 23149 invoked by uid 0); 12 Dec 2015 20:54:19 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy2.mail.unifiedlayer.com with SMTP; 12 Dec 2015 20:54:19 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id sra81r00M1MNPNq01raBic; Sat, 12 Dec 2015 20:34:17 -0700 X-Authority-Analysis: v=2.1 cv=Caqbutbl c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=wUQvQvOEmiQA:10 a=jqBRFv0mrdUA:10 a=48vgC7mUAAAA:8 a=bfLuiRfvAAAA:8 a=yakATiurAAAA:8 a=P8ZqZ5N8lTChCQ9axC0A:9 a=uTgAstlzGdobUT8s:21 a=LFgWvnaaNTCvwimg:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=9a085LanoJ2E2fRiH+Oa94YSlSi+WmJWkCQUby6b39k=; b=MaRG8qYvkUnpuzvqw9Bz/EV0bUddOZl2jKSSSxftxDeJiTihZqv/qDX2twvH2weq3Qgztmspgi3X4mJpF/JwREvNCxpWC1Vvz7X8u7F1T0BaGh+qaJ92rXmuKeR3GdtE; Received: from [100.36.26.202] (port=54045 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1a7qrq-0001YX-Nl; Sat, 12 Dec 2015 13:34:10 -0700 User-Agent: Microsoft-MacOutlook/0.0.0.151105 Date: Sat, 12 Dec 2015 15:34:02 -0500 From: Richard Shockey To: Eric Burger , Message-ID: Thread-Topic: [Modern] Problem statement draft as working group document References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us} Archived-At: Subject: Re: [Modern] Problem statement draft as working group document X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, 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, 12 Dec 2015 20:54:23 -0000 +1 =20 It still seems to be =E2=80=9Cend world hunger week=E2=80=9D=E2=80=A6 Steve I don=E2=80=99t know how you define consensus ..but it still strikes me tha= t consensus on what is the real problem is very weak.=20 On 12/10/15, 8:05 PM, "Modern on behalf of Eric Burger" wrote: >Nah. :-) > >> On Dec 10, 2015, at 1:40 PM, Steve Donovan wr= ote: >>=20 >> There has been no response to this so I'm going to suggest we put a dead= line on opinions. >>=20 >> Please express your opinion on making draft-peterson-modern-problems-02 = a working group document before Thursday, December 17th. >>=20 >> It is important that anyone who supports the promotion of the document a= lso express their opinion. >>=20 >> Thanks, >>=20 >> Steve >>=20 >> On 11/13/15 3:53 PM, Steve Donovan wrote: >>> All, >>>=20 >>> During the IETF94 MODERN WG meeting there was consensus that draft-pete= rson-modern-problems-02 be accepted as a working group document. This would= be to address the architecture Architecture Overview milestone. >>>=20 >>> It was recognized that it is not in final form but would be a good star= ting point for the architecture overview. >>>=20 >>> Please comment on whether or not this should become a working group doc= ument. >>>=20 >>> Regards, >>>=20 >>> Steve >>>=20 >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern >>=20 >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern From nobody Mon Dec 14 06:44: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 59A7F1A1BF6 for ; Mon, 14 Dec 2015 06:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEKolKqA827J for ; Mon, 14 Dec 2015 06:44:06 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34DF71A1BEF for ; Mon, 14 Dec 2015 06:44:06 -0800 (PST) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:63820 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1a8UM6-000T0Z-UL for modern@ietf.org; Mon, 14 Dec 2015 06:44:05 -0800 To: modern@ietf.org References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> From: Steve Donovan Message-ID: <566ED5B1.4040907@usdonovans.com> Date: Mon, 14 Dec 2015 08:44:01 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Archived-At: Subject: Re: [Modern] Problem statement draft as working group document X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, 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, 14 Dec 2015 14:44:07 -0000 inline... On 12/12/15 2:34 PM, Richard Shockey wrote: > > +1 > > > > It still seems to be “end world hunger week”… SRD> I would hope we could advance this discussion without sarcasm and snarkiness. I interpret your response and Eric's response as an indication that you do not think that draft-peterson-modern-problems-02 should not become a working group draft. I'm sure both of you will let me know if I have interpreted your responses incorrectly. > > Steve I don’t know how you define consensus ..but it still strikes me that consensus on what is the real problem is very weak. SRD> I am not at liberty to define consensus, that is in the preview of the ADs. I am simply asking the working group if a document should become a working group item. There were no objections expressed during the meeting in Yokohama, which is an indication of consensus. The next step is to verify that consensus on the list. That is what we are in the process of doing. SRD> It would be very helpful if you could elaborate on why you think the document should not become a working group item. > > > On 12/10/15, 8:05 PM, "Modern on behalf of Eric Burger" wrote: > >> Nah. :-) >> >>> On Dec 10, 2015, at 1:40 PM, Steve Donovan wrote: >>> >>> There has been no response to this so I'm going to suggest we put a deadline on opinions. >>> >>> Please express your opinion on making draft-peterson-modern-problems-02 a working group document before Thursday, December 17th. >>> >>> It is important that anyone who supports the promotion of the document also express their opinion. >>> >>> Thanks, >>> >>> Steve >>> >>> On 11/13/15 3:53 PM, Steve Donovan wrote: >>>> All, >>>> >>>> During the IETF94 MODERN WG meeting there was consensus that draft-peterson-modern-problems-02 be accepted as a working group document. This would be to address the architecture Architecture Overview milestone. >>>> >>>> It was recognized that it is not in final form but would be a good starting point for the architecture overview. >>>> >>>> Please comment on whether or not this should become a working group document. >>>> >>>> Regards, >>>> >>>> Steve >>>> >>>> _______________________________________________ >>>> Modern mailing list >>>> Modern@ietf.org >>>> https://www.ietf.org/mailman/listinfo/modern >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Mon Dec 14 06: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 61EC61A1EB7 for ; Mon, 14 Dec 2015 06:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZxNa1YYg0Td for ; Mon, 14 Dec 2015 06:45:16 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87D371A1BEF for ; Mon, 14 Dec 2015 06:44:53 -0800 (PST) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:63823 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1a8UMt-000Tni-V4 for modern@ietf.org; Mon, 14 Dec 2015 06:44:53 -0800 To: modern@ietf.org References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> From: Steve Donovan Message-ID: <566ED5E3.9020203@usdonovans.com> Date: Mon, 14 Dec 2015 08:44:51 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000808020408060305040507" X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Archived-At: Subject: Re: [Modern] Problem statement draft as working group document X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, 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, 14 Dec 2015 14:45:19 -0000 This is a multi-part message in MIME format. --------------000808020408060305040507 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Eric, Could you elaborate on why you think the document should not become a working group item. Thanks, Steve On 12/10/15 7:05 PM, Eric Burger wrote: > Nah. :-) > >> On Dec 10, 2015, at 1:40 PM, Steve Donovan wrote: >> >> There has been no response to this so I'm going to suggest we put a deadline on opinions. >> >> Please express your opinion on making draft-peterson-modern-problems-02 a working group document before Thursday, December 17th. >> >> It is important that anyone who supports the promotion of the document also express their opinion. >> >> Thanks, >> >> Steve >> >> On 11/13/15 3:53 PM, Steve Donovan wrote: >>> All, >>> >>> During the IETF94 MODERN WG meeting there was consensus that draft-peterson-modern-problems-02 be accepted as a working group document. This would be to address the architecture Architecture Overview milestone. >>> >>> It was recognized that it is not in final form but would be a good starting point for the architecture overview. >>> >>> Please comment on whether or not this should become a working group document. >>> >>> Regards, >>> >>> Steve >>> >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern > > > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern --------------000808020408060305040507 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Eric,

Could you elaborate on why you think the document should not become a working group item.
Thanks,

Steve

On 12/10/15 7:05 PM, Eric Burger wrote:
Nah. :-)


On Dec 10, 2015, at 1:40 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:

There has been no response to this so I'm going to suggest we put a deadline on opinions.

Please express your opinion on making draft-peterson-modern-problems-02 a working group document before Thursday, December 17th.

It is important that anyone who supports the promotion of the document also express their opinion.

Thanks,

Steve

On 11/13/15 3:53 PM, Steve Donovan wrote:

All,

During the IETF94 MODERN WG meeting there was consensus that draft-peterson-modern-problems-02 be accepted as a working group document.  This would be to address the architecture Architecture Overview milestone.

It was recognized that it is not in final form but would be a good starting point for the architecture overview.

Please comment on whether or not this should become a working group document.

Regards,

Steve

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

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


      

      

      

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


    

    

  


--------------000808020408060305040507--


From nobody Mon Dec 14 07:52:31 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBAF91A86F7 for ; Mon, 14 Dec 2015 07:52:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level: 
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-yhnQ5KUFoq for ; Mon, 14 Dec 2015 07:52:26 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0725.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:725]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1AEB1A7021 for ; Mon, 14 Dec 2015 07:52:25 -0800 (PST)
Received: from BL2FFO11FD023.protection.gbl (10.173.160.31) by BL2FFO11HUB037.protection.gbl (10.173.160.241) with Microsoft SMTP Server (TLS) id 15.1.346.13; Mon, 14 Dec 2015 15:52:06 +0000
Authentication-Results: spf=pass (sender IP is 144.230.32.80) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com;
Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.32.80 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.80; helo=preapdm1.corp.sprint.com;
Received: from preapdm1.corp.sprint.com (144.230.32.80) by BL2FFO11FD023.mail.protection.outlook.com (10.173.161.102) with Microsoft SMTP Server (TLS) id 15.1.346.13 via Frontend Transport; Mon, 14 Dec 2015 15:52:06 +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 tBEE1Wiv006775;  Mon, 14 Dec 2015 10:52:05 -0500
Received: from plswe13m07.ad.sprint.com (plswe13m07.corp.sprint.com [144.229.214.26]) by preapdm1.corp.sprint.com with ESMTP id 1yrgxf62pp-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 14 Dec 2015 10:52:05 -0500
Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 14 Dec 2015 09:52:04 -0600
Received: from PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed]) by PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed%24]) with mapi id 15.00.1076.000; Mon, 14 Dec 2015 09:52:04 -0600
From: "Gorman, Pierce A [CTO]" 
To: Steve Donovan , "modern@ietf.org" 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHRNn38KCigIa6jakmAIZNM6lCGV57Kn4nQ
Date: Mon, 14 Dec 2015 15:52:04 +0000
Message-ID: 
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com>  <566ED5E3.9020203@usdonovans.com>
In-Reply-To: <566ED5E3.9020203@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.214.116.44]
Content-Type: multipart/alternative; boundary="_000_e14b0f610de642f9a0c6e7e0a17915d3PLSWE13M08adsprintcom_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD023; 1:RdcXdAB424QuwYIjOsFWpQbqychzgUQTIXDS5GSQlyKNzWq2pI2pC/PeZRef9rKKwOKJ+0sXEGoMjwHicHwj2rrR/JFXg6mBi1iXlA1VoTu4UkcWrxgwmA09m+2BXwzQeXyCi6LXsdQMGR80AWcuoLW+39voumj820VcCz1Pd9VPhC3H0G67sHbOGfPGY/2whRYmSRl9XXh6g8HsdTrJcz37wbU0ThII7KI18VZtzJehHgAViCbH+VqF4pkZMUpJs38T9P1WKAbwO86G0jU87bPgtOGAJz82JzxP9HpNfdSxlthEBNgjqMoRNw/41LI01PIa6sEhPMii5SwOUg4ff/e1hERXm3w7mTLQhw8BvYMcg6WE31gdj/pNhHws6sZODBIynOpvzhY4J5A/vQrxFw==
X-Forefront-Antispam-Report: CIP:144.230.32.80; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(438002)(377454003)(164054003)(189002)(199003)(24454002)(479174004)(300700001)(81156007)(102836003)(19580405001)(19580395003)(93886004)(5001770100001)(2900100001)(76176999)(19300405004)(86362001)(16236675004)(512954002)(33646002)(19617315012)(87936001)(15975445007)(5250100002)(4546004)(92566002)(5003600100002)(50986999)(2501003)(2950100001)(3846002)(5008740100001)(6806005)(790700001)(107886002)(586003)(6116002)(260700001)(84326002)(108616004)(106116001)(1220700001)(1096002)(189998001)(54356999)(106466001)(19625215002)(5004730100002)(24736003)(5001960100002)(11100500001)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB037; H:preapdm1.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB037; 2:8/E+0t35enpCBTzgnSaCpofuoobCFQC8qTOy0Kn0UIqLuXbbsRChIN86/Xj7rZviTuXE8SNIL/Guw7lATbmFI+TvkZJQFkKQVJwwmvlDH9y9DNU45zJZsvYOT22VyrTBMXIBa5F2qzF/8eSL0MeNHA==; 3:uZEeni+5cpv/2tW4Z1X4vzCvDBMv2z3uB6xDLA75m5DF+mHL5EPUB++Ft4Edpqg/iRpQAwgYwxL8z1YWyx/qMPwWGQtpHvgLJ+OmL266qwyTKwzVmaDInz3NTOA2TRLk8XtVOa/nM3D36hrCVUYvy1VyoTYheuS1+U/McwHE0tc4Q0YcvDy/17xsLso5ZRcmnSqqCaG2EazXpOVRJDX3f22taAScBSDdtQheMOpbDC1KWoF/Hey+x67hWiobMtWIabqXGctoJSUNrboDRjGKOQ==; 25:VdKGmsZ4TFXWGihcnz/CcRXnH0ya/OAII77+1r6XOuRyk0L3N89adSQz9hWUWIo74JGOoEmC5R4GqmfEJayNenfWaK6xpdG6g2prUEFtPWcMzWMRIYXQD0ahcV15GbpexxxVk8xYffYtez1kMCi29cEs7wDfq2Z4BcW8APEffQNBvjYLNB4VWdX7khQlYP/lQusxze9gSJFEnlomTJKkMCkHeQx19RI83VUduMNut7rzWEbvOYtm7REya7tSZWUeI+Lb0v2q/14+HmYouzimyg==
X-Exchange-Antispam-Report-Test: UriScan:; BCL:0; PCL:0; RULEID:(8251501002);  SRVR:BL2FFO11HUB037; UriScan:; 
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB037; 20:l4vx0gsdLCCIBvEreTX7fE5mhAcwFBmzyqZLQcReRT7tI/1xBTpxjs15YaWnydA6EnVAB/bKFre1n7C4xs+GuU7STB3IkRlqBEs2deYTdbnttD3rN7GWNC05za4R8rlzEQfSywIy8bKHC/9Y1DL+A6mbukMqMYyuuCHSFj0RgxatV6YAyqZn852Qflz5y59Pzqzh53IQLM0SyI0nb8uOMt0DUK3jiVfm3jAv4bfcsUK7SqkplcadJIK0+WECZg8v; 4:jIhs9DfeDAsgEIPa7om6vbZkWE4Job6CyhUhMeE+epi6aB2fuj9aUdD7EhZpVcDCJ2xaxtpJpepay5vk1Va1UbzGJOnbrXCugFLGkQqraQvhqSvMcS/PhSk7+knlX2YHxa3rKFA4SoWVRMShNlCcuayu337hJgtHZoQ1Ne8W76zV8d5I17ks01bU1R8f/ggkLfkQCPdy9vioVoqb4CAxPLR0GmQRqa31OSJFATV7EeSPHyd3/CCgQkBt1Gbj33pfnnNTAtxL+69yD63j6gQu2ujOocmDycuy6UhxBeENAMLMoECrRN/R4wGWU2U2a8RzHnTKNzMQtpL/vAQw5HdAJoGdvPCyp4jqmmtWb7qGwc5vDsjlfbyAfmxlYBvavqRK
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:BL2FFO11HUB037; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB037; 
X-Forefront-PRVS: 0790FB1F33
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2FFO11HUB037; 23:efbIjQjyq+/uRwjs7oRDLhYEBsSKKpVxQ40lEpeZ?= =?us-ascii?Q?/g8k+m968Tb6sh2xh7I4m/GkML9KSanikhRutgwx4xbX7PZ4tqnD7O2rQ4Uu?= =?us-ascii?Q?rVyWR8gEpYPTWH9bi+LbQVw6jW99yzsCUe+1gZBbMLzmfYYVVeTBbaNwqLf8?= =?us-ascii?Q?NGmVe8luMwvIXmREPM0j5vghQaQyamS6sxKSCWl5nf93Q/l8W3/8rE5G+nhG?= =?us-ascii?Q?WafYP3Wt1ILbPXlrb8mPbJ5A9xbUYGanihkVtg6melK+W3Rn2hIVp8HhZ6bo?= =?us-ascii?Q?8IFPs1gswk02PBWWoQI09AWJkWmYZDJJJgh6ouHwFxphrFTYCPa8114Cs1pf?= =?us-ascii?Q?ber79IclivM3Qc/drYi1J58Vw+uUd3pXGCmC6OtAhmYV1enuyTe//vrMqY1v?= =?us-ascii?Q?FI7HKB7AFRnWEn94CcCTYAKgO/fgpxVeam+p3GS6km0YsB8RVxVVnGWpJ59d?= =?us-ascii?Q?bgigJ2z/De39eeGlqCCTuiXzJTA7c/+frcoaLN3j4D/GApxbL444aZCW1Jy3?= =?us-ascii?Q?bhgU+hn+TuejP52ejiF5bsUQORK2gMEU/oSUyQ+EsmbQgBk0WpvWTwCK/Df1?= =?us-ascii?Q?YRdyfTCuIGm/oFz5xoCFhgP2dZevlCpCK6CYSkJrvVDfgyyS/oTGPfhCs3ae?= =?us-ascii?Q?7wbQRWCK3Mvbx/zxiJDmsY/mIw/2fz58IwhXbT8Sd0iVIY1u/QnL/EagxjuB?= =?us-ascii?Q?TUy89kDm9nE4A9JpVeckKp/CLtuVjPJGAss9Sx2HXCV5WWQE9SRcL5/LoZY3?= =?us-ascii?Q?ALKz2m6EUXU85sdlIE6XBpJfSHz1pdw42wwyrdl1H2OPyxMfbpM00jy4/VLb?= =?us-ascii?Q?+ehc0irc55eoplHS3DS2WCvs5+ZkXg8qdEV6BbDMgvCV18mC3nojRYWb27dI?= =?us-ascii?Q?0HKzaT+ocof4DsX3XsX4luq3gcXdEixtkr4dCaFL7wMAok+k4xG/c3yl4AlK?= =?us-ascii?Q?sg1+wSICAM8iYAPQMPp/8RO0gtXKGn8ErjLuLnu+9DuMPT1hji7Mg8kFE6yr?= =?us-ascii?Q?ouqyUX1pS9XX1HLW1SiPWm5tYQ2e3+vy0Ti/NF2v1O9KM9Fo5aLDKo01WdLh?= =?us-ascii?Q?WJncpvRwXjEdm+PZPRzFekEXYutpC62V85zc8a+WgJ73YWCuKk64uUyUsZ/Z?= =?us-ascii?Q?6SyLlc9BzTyUS/ZjXle66N9GdX9i5rCKbmsv0JvL4PBbgv1Qb9nvATkYFWwZ?= =?us-ascii?Q?smzP6ZZIsVOIwLRVRZz3wPLie+edVRFP7vDw8SQdQJgPYBAuPf4Ey6cgkFHN?= =?us-ascii?Q?hBALOKFTpNSVqHAm2M0siKo/uDIDN98YAQyLc7q7THuZsPH22v9gsAj1xr4q?= =?us-ascii?Q?hdvN1u9n2BRfDzsql0+2uM2y27RNXuydHN0k9Ocd/k0hb5lIBlZEM+VU08Kh?= =?us-ascii?Q?s+663emSSVV3yqQPweAXvke/SV/vR1rFYTTRHjY0ATYWgLrKkNSGQXVVYnUS?= =?us-ascii?Q?L277tRRhNA=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB037; 5:xZt2Lgva9aYCnBJTuTasraVNXjsyhIIGZXaeeY1llGELx4Cw4Hnx/V1VUc3pjWhX/e5HZV6ptupD3tb5rb3qe3SOjKaNTazTH9Dinb+RbjgdF6KDhq9GR92S6ss1kY0y7DG6bTXbEcZPy34CAYWMUQ==; 24:I/68eYEzkC+yfW2GMx+VWCTK75jg1yDBsrbuKrpzjy45/4XmVElQe4FMSrQl9p4QlhoUoVOxiTqf3eWFpRB9snshrnqYoBfaRWvVy/CYPiY=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: sprint.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Dec 2015 15:52:06.2700 (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: BL2FFO11HUB037
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 14 Dec 2015 15:52:30 -0000

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

If an actual reason is not required I would like to add my vote of dissensi=
on on principal without having to actually read the "draft-peterson-modern-=
problems-02".  You might recall I argued with the language in the charter b=
ut I and others were over-ruled by the Area Directors.

Pierce Gorman

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: December 14, 2015 8:45 AM
To: modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

Eric,

Could you elaborate on why you think the document should not become a worki=
ng group item.

Thanks,

Steve
On 12/10/15 7:05 PM, Eric Burger wrote:

Nah. :-)



On Dec 10, 2015, at 1:40 PM, Steve Donovan  wrote:



There has been no response to this so I'm going to suggest we put a deadlin=
e on opinions.



Please express your opinion on making draft-peterson-modern-problems-02 a w=
orking group document before Thursday, December 17th.



It is important that anyone who supports the promotion of the document also=
 express their opinion.



Thanks,



Steve



On 11/13/15 3:53 PM, Steve Donovan wrote:

All,



During the IETF94 MODERN WG meeting there was consensus that draft-peterson=
-modern-problems-02 be accepted as a working group document.  This would be=
 to address the architecture Architecture Overview milestone.



It was recognized that it is not in final form but would be a good starting=
 point for the architecture overview.



Please comment on whether or not this should become a working group documen=
t.



Regards,



Steve



_______________________________________________

Modern mailing list

Modern@ietf.org

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



_______________________________________________

Modern mailing list

Modern@ietf.org

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






_______________________________________________

Modern mailing list

Modern@ietf.org

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


________________________________

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_e14b0f610de642f9a0c6e7e0a17915d3PLSWE13M08adsprintcom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











If an actual reason is not required I w=
ould like to add my vote of dissension on principal without having to actua=
lly read the “draft-peterson-modern-problems-02&#=
8221;. 
 You might recall I argued with the language in the charter but I and other=
s were over-ruled by the Area Directors.


 


Pierce Gorman


 






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

Sent: December 14, 2015 8:45 AM

To: modern@ietf.org

Subject: Re: [Modern] Problem statement draft as working group docum=
ent






 


Eric,



Could you elaborate on why you think the document should not become a worki=
ng group item.






Thanks,



Steve




On 12/10/15 7:05 PM, Eric Burger wrote:





Nah. :-)


 




On Dec 10, 2015, at 1:40 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 


There has been no response to this so I'm going to suggest we put a de=
adline on opinions.


 


Please express your opinion on making draft-peterson-modern-problems-0=
2 a working group document before Thursday, December 17th.


 


It is important that anyone who supports the promotion of the document=
 also express their opinion.


 


Thanks,


 


Steve


 


On 11/13/15 3:53 PM, Steve Donovan wrote:




All,


 


During the IETF94 MODERN WG meeting there was consensus that draft-pet=
erson-modern-problems-02 be accepted as a working group document.  Thi=
s would be to address the architecture Architecture Overview milestone.


 


It was recognized that it is not in final form but would be a good sta=
rting point for the architecture overview.


 


Please comment on whether or not this should become a working group do=
cument.


 


Regards,


 


Steve


 


_______________________________________________


Modern mailing list


Modern@ietf.org

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




 


_______________________________________________


Modern mailing list


Modern@ietf.org

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




 











_______________________________________________


Modern mailing list


Modern@ietf.org

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




 









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





--_000_e14b0f610de642f9a0c6e7e0a17915d3PLSWE13M08adsprintcom_--


From nobody Mon Dec 14 09:52:01 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8D11ACF55 for ; Mon, 14 Dec 2015 09:51:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level: 
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] 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 h0HyxOC0vjPN for ; Mon, 14 Dec 2015 09:51:57 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 2DC1E1ACEC2 for ; Mon, 14 Dec 2015 09:51:57 -0800 (PST)
Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id tBEHoAYk003593; Mon, 14 Dec 2015 12:51:57 -0500
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049295.ppops.net-00191d01. with ESMTP id 1yrgds186x-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);  Mon, 14 Dec 2015 12:51:56 -0500
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 tBEHptG4013036; Mon, 14 Dec 2015 12:51:55 -0500
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 tBEHpgqS012872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Dec 2015 12:51:47 -0500
Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Mon, 14 Dec 2015 17:51:32 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.78]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0248.002; Mon, 14 Dec 2015 12:51:31 -0500
From: "DOLLY, MARTIN C" 
To: "Gorman, Pierce A [CTO]" , Steve Donovan , "modern@ietf.org" 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHRNn38t9tG2eQFXECnCpoLN3xbKp7K9ZYA///NcIA=
Date: Mon, 14 Dec 2015 17:51:30 +0000
Message-ID: 
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com>  <566ED5E3.9020203@usdonovans.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.200.21]
Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E8365615D50F49MISOUT7MSGUSRDB_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-12-14_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310007 definitions=main-1512140299
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 14 Dec 2015 17:52:00 -0000

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

I agree with Pierce

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Gorman, Pierce A=
 [CTO]
Sent: Monday, December 14, 2015 10:52 AM
To: Steve Donovan ; modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

If an actual reason is not required I would like to add my vote of dissensi=
on on principal without having to actually read the "draft-peterson-modern-=
problems-02".  You might recall I argued with the language in the charter b=
ut I and others were over-ruled by the Area Directors.

Pierce Gorman

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: December 14, 2015 8:45 AM
To: modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

Eric,

Could you elaborate on why you think the document should not become a worki=
ng group item.
Thanks,

Steve
On 12/10/15 7:05 PM, Eric Burger wrote:

Nah. :-)



On Dec 10, 2015, at 1:40 PM, Steve Donovan  wrote:



There has been no response to this so I'm going to suggest we put a deadlin=
e on opinions.



Please express your opinion on making draft-peterson-modern-problems-02 a w=
orking group document before Thursday, December 17th.



It is important that anyone who supports the promotion of the document also=
 express their opinion.



Thanks,



Steve



On 11/13/15 3:53 PM, Steve Donovan wrote:

All,



During the IETF94 MODERN WG meeting there was consensus that draft-peterson=
-modern-problems-02 be accepted as a working group document.  This would be=
 to address the architecture Architecture Overview milestone.



It was recognized that it is not in final form but would be a good starting=
 point for the architecture overview.



Please comment on whether or not this should become a working group documen=
t.



Regards,



Steve



_______________________________________________

Modern mailing list

Modern@ietf.org

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



_______________________________________________

Modern mailing list

Modern@ietf.org

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





_______________________________________________

Modern mailing list

Modern@ietf.org

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


________________________________

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_E42CCDDA6722744CB241677169E8365615D50F49MISOUT7MSGUSRDB_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I agree with Pierce=



 






From: Modern [mailto:modern-bounces@ietf.org]
On Behalf Of Gorman, Pierce A [CTO]

Sent: Monday, December 14, 2015 10:52 AM

To: Steve Donovan <srdonovan@usdonovans.com>; modern@ietf.org<=
br>
Subject: Re: [Modern] Problem statement draft as working group docum=
ent






 


If an actual reason is not required I w=
ould like to add my vote of dissension on principal without having to actua=
lly read the “draft-peterson-modern-problems-02&#=
8221;. 
 You might recall I argued with the language in the charter but I and other=
s were over-ruled by the Area Directors.


 


Pierce Gorman


 






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

Sent: December 14, 2015 8:45 AM

To: modern@ietf.org

Subject: Re: [Modern] Problem statement draft as working group docum=
ent






 


Eric,



Could you elaborate on why you think the document should not become a worki=
ng group item.


Thanks,



Steve




On 12/10/15 7:05 PM, Eric Burger wrote:





Nah. :-)


 




On Dec 10, 2015, at 1:40 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 


There has been no response to this so I'm going to suggest we put a de=
adline on opinions.


 


Please express your opinion on making draft-peterson-modern-problems-0=
2 a working group document before Thursday, December 17th.


 


It is important that anyone who supports the promotion of the document=
 also express their opinion.


 


Thanks,


 


Steve


 


On 11/13/15 3:53 PM, Steve Donovan wrote:




All,


 


During the IETF94 MODERN WG meeting there was consensus that draft-pet=
erson-modern-problems-02 be accepted as a working group document.  Thi=
s would be to address the architecture Architecture Overview milestone.


 


It was recognized that it is not in final form but would be a good sta=
rting point for the architecture overview.


 


Please comment on whether or not this should become a working group do=
cument.


 


Regards,


 


Steve


 


_______________________________________________


Modern mailing list


Modern@ietf.org

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




 


_______________________________________________


Modern mailing list


Modern@ietf.org

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




 









_______________________________________________


Modern mailing list


Modern@ietf.org

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




 


 










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






--_000_E42CCDDA6722744CB241677169E8365615D50F49MISOUT7MSGUSRDB_--


From nobody Mon Dec 14 09:58:20 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE161AD1C3 for ; Mon, 14 Dec 2015 09:58:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level: 
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] 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 w3dJalj8IdPv for ; Mon, 14 Dec 2015 09:58:15 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 945651AD277 for ; Mon, 14 Dec 2015 09:58:15 -0800 (PST)
Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id tBEHs1KW007827; Mon, 14 Dec 2015 12:58:15 -0500
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049295.ppops.net-00191d01. with ESMTP id 1yrgds1acq-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);  Mon, 14 Dec 2015 12:58:15 -0500
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 tBEHwDg5020022; Mon, 14 Dec 2015 12:58:13 -0500
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 tBEHw4ue019901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Dec 2015 12:58:09 -0500
Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 14 Dec 2015 17:57:43 GMT
Received: from MISOUT7MSGUSRDD.ITServices.sbc.com ([169.254.4.7]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0248.002; Mon, 14 Dec 2015 12:57:43 -0500
From: "PFAUTZ, PENN L" 
To: "Gorman, Pierce A [CTO]" , Steve Donovan , "modern@ietf.org" 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHRNod+iGM/I+6CPkS8NH280U5tDJ7KwzDQ
Date: Mon, 14 Dec 2015 17:57:42 +0000
Message-ID: <38726EDA2109264987B45E29E758C4D60592552D@MISOUT7MSGUSRDD.ITServices.sbc.com>
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com>  <566ED5E3.9020203@usdonovans.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.59.176]
Content-Type: multipart/alternative; boundary="_000_38726EDA2109264987B45E29E758C4D60592552DMISOUT7MSGUSRDD_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-12-14_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310007 definitions=main-1512140300
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 14 Dec 2015 17:58:18 -0000

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

I find that I need to object as well. It is not numbering that drives inter=
connection so much as interconnection drives numbering. As the evolution of=
 interconnection even as the PSTN migrates to an IP backbone is by no means=
 settled I'm concerned that we are getting the cart before the horse. I als=
o object to the conclusory statements about user and service provider roles=
; I think the picture is more complicated.
I remain sympathetic to the goal of modernizing number administration and r=
outing but the document is problematic for me.

Penn Pfautz
AT&T Global Connection Management


From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com]
Sent: Monday, December 14, 2015 10:52 AM
To: Steve Donovan; modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

If an actual reason is not required I would like to add my vote of dissensi=
on on principal without having to actually read the "draft-peterson-modern-=
problems-02".  You might recall I argued with the language in the charter b=
ut I and others were over-ruled by the Area Directors.

Pierce Gorman

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: December 14, 2015 8:45 AM
To: modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

Eric,

Could you elaborate on why you think the document should not become a worki=
ng group item.
Thanks,

Steve
On 12/10/15 7:05 PM, Eric Burger wrote:

Nah. :-)



On Dec 10, 2015, at 1:40 PM, Steve Donovan  wrote:



There has been no response to this so I'm going to suggest we put a deadlin=
e on opinions.



Please express your opinion on making draft-peterson-modern-problems-02 a w=
orking group document before Thursday, December 17th.



It is important that anyone who supports the promotion of the document also=
 express their opinion.



Thanks,



Steve



On 11/13/15 3:53 PM, Steve Donovan wrote:

All,



During the IETF94 MODERN WG meeting there was consensus that draft-peterson=
-modern-problems-02 be accepted as a working group document.  This would be=
 to address the architecture Architecture Overview milestone.



It was recognized that it is not in final form but would be a good starting=
 point for the architecture overview.



Please comment on whether or not this should become a working group documen=
t.



Regards,



Steve



_______________________________________________

Modern mailing list

Modern@ietf.org

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



_______________________________________________

Modern mailing list

Modern@ietf.org

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





_______________________________________________

Modern mailing list

Modern@ietf.org

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


________________________________

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_38726EDA2109264987B45E29E758C4D60592552DMISOUT7MSGUSRDD_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I find that I need to object as well.=
 It is not numbering that drives interconnection so much as interconnection=
 drives numbering. As the evolution of interconnection
 even as the PSTN migrates to an IP backbone is by no means settled I’=
;m concerned that we are getting the cart before the horse. I also object t=
o the conclusory statements about user and service provider roles; I think =
the picture is more complicated.


I remain sympathetic to the goal of m=
odernizing number administration and routing but the document is problemati=
c for me.


 


Penn Pfautz


AT&T Global Connection Management=



 


 






From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com]


Sent: Monday, December 14, 2015 10:52 AM

To: Steve Donovan; modern@ietf.org

Subject: Re: [Modern] Problem statement draft as working group docum=
ent






 


If an actual reason is not required I w=
ould like to add my vote of dissension on principal without having to actua=
lly read the “draft-peterson-modern-problems-02&#=
8221;. 
 You might recall I argued with the language in the charter but I and other=
s were over-ruled by the Area Directors.


 


Pierce Gorman


 






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

Sent: December 14, 2015 8:45 AM

To: modern@ietf.org

Subject: Re: [Modern] Problem statement draft as working group docum=
ent






 


Eric,



Could you elaborate on why you think the document should not become a worki=
ng group item.


Thanks,



Steve




On 12/10/15 7:05 PM, Eric Burger wrote:





Nah. :-)


 




On Dec 10, 2015, at 1:40 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 


There has been no response to this so I'm going to suggest we put a de=
adline on opinions.


 


Please express your opinion on making draft-peterson-modern-problems-0=
2 a working group document before Thursday, December 17th.


 


It is important that anyone who supports the promotion of the document=
 also express their opinion.


 


Thanks,


 


Steve


 


On 11/13/15 3:53 PM, Steve Donovan wrote:




All,


 


During the IETF94 MODERN WG meeting there was consensus that draft-pet=
erson-modern-problems-02 be accepted as a working group document.  Thi=
s would be to address the architecture Architecture Overview milestone.


 


It was recognized that it is not in final form but would be a good sta=
rting point for the architecture overview.


 


Please comment on whether or not this should become a working group do=
cument.


 


Regards,


 


Steve


 


_______________________________________________


Modern mailing list


Modern@ietf.org

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




 


_______________________________________________


Modern mailing list


Modern@ietf.org

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




 









_______________________________________________


Modern mailing list


Modern@ietf.org

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




 


 










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






--_000_38726EDA2109264987B45E29E758C4D60592552DMISOUT7MSGUSRDD_--


From nobody Mon Dec 14 10:25: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 0C6541B2D19 for ; Mon, 14 Dec 2015 10:25:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level: 
X-Spam-Status: No, score=-1.666 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Efwq7deBdH9a for ; Mon, 14 Dec 2015 10:25:15 -0800 (PST)
Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 2E7B81B2D0E for ; Mon, 14 Dec 2015 10:25:15 -0800 (PST)
Received: (qmail 23691 invoked by uid 0); 14 Dec 2015 18:25:13 -0000
Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy2.mail.unifiedlayer.com with SMTP; 14 Dec 2015 18:25:13 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with  id tW591r01A1MNPNq01W5CKE; Mon, 14 Dec 2015 11:05:13 -0700
X-Authority-Analysis: v=2.1 cv=IekUBwaa c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=P34Qx31D9VQA:10 a=wUQvQvOEmiQA:10 a=jqBRFv0mrdUA:10 a=48vgC7mUAAAA:8 a=bfLuiRfvAAAA:8 a=yakATiurAAAA:8 a=giKFeqini2K5ADqw3o8A:9 a=eeOXeWFrFXY6XfBD:21 a=-quzaob25FgFYbxo:21 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us;  s=default;  h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=PVURxOGXGv4msa94j82vMG00PppDmzBHrWB7q3CswZE=;  b=cKdEk/8bN2NwJy7+65MulfBborSVxj3px/G1k4rirjYIaBELxYMf8fCygFj7MhCFb1bkLHtRDm+qf2otMffV2ie/W2XNJqfAP2se6JAQ3C4I+46xwDkQ6LAVAdot5eGF;
Received: from [69.241.19.12] (port=1448 helo=[10.36.94.120]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1a8XUj-0006J5-HA; Mon, 14 Dec 2015 11:05:09 -0700
User-Agent: Microsoft-MacOutlook/0.0.0.151105
Date: Mon, 14 Dec 2015 13:05:02 -0500
From: Richard Shockey 
To: Steve Donovan , 
Message-ID: 
Thread-Topic: [Modern] Problem statement draft as working group document
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com>   <566ED5B1.4040907@usdonovans.com>
In-Reply-To: <566ED5B1.4040907@usdonovans.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 69.241.19.12 authed with richard+shockey.us}
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 14 Dec 2015 18:25:20 -0000

>inline...
>
>On 12/12/15 2:34 PM, Richard Shockey wrote:
>>
>> +1 
>>  =20
>>
>>
>> It still seems to be =E2=80=9Cend world hunger week=E2=80=9D=E2=80=A6
>SRD> I would hope we could advance this discussion without sarcasm and=20
>snarkiness. =20

RS>  You can certainly hope.


>I interpret your response and Eric's response as an=20
>indication that you do not think that draft-peterson-modern-problems-02=20
>should not become a working group draft.  I'm sure both of you will let=20
>me know if I have interpreted your responses incorrectly.


RS>  You have correctly interpreted my position. And BTW I=E2=80=99m in total agr=
eement with the sentiments of both Martin Dolly and Pierce Gorman. Our issue=
 was the charter itself which in due course has lead to a over reaching prob=
lem and I do not support either. =20




>>
>> Steve I don=E2=80=99t know how you define consensus ..but it still strikes me =
that consensus on what is the real problem is very weak.
>SRD> I am not at liberty to define consensus, that is in the preview of=20
>the ADs.  I am simply asking the working group if a document should=20
>become a working group item.  There were no objections expressed during=20
>the meeting in Yokohama, which is an indication of consensus.  The next=20
>step is to verify that consensus on the list.  That is what we are in=20
>the process of doing.


RS> Agreed. I=E2=80=99m not concerned about what happened in Yokohama.  It is irr=
elevant to what this discussion is about.=20


>
>SRD> It would be very helpful if you could elaborate on why you think=20
>the document should not become a working group item.
>>
>>
>> On 12/10/15, 8:05 PM, "Modern on behalf of Eric Burger"  wrote:
>>
>>> Nah. :-)
>>>
>>>> On Dec 10, 2015, at 1:40 PM, Steve Donovan  =
wrote:
>>>>
>>>> There has been no response to this so I'm going to suggest we put a de=
adline on opinions.
>>>>
>>>> Please express your opinion on making draft-peterson-modern-problems-0=
2 a working group document before Thursday, December 17th.
>>>>
>>>> It is important that anyone who supports the promotion of the document=
 also express their opinion.
>>>>
>>>> Thanks,
>>>>
>>>> Steve
>>>>
>>>> On 11/13/15 3:53 PM, Steve Donovan wrote:
>>>>> All,
>>>>>
>>>>> During the IETF94 MODERN WG meeting there was consensus that draft-pe=
terson-modern-problems-02 be accepted as a working group document.  This wou=
ld be to address the architecture Architecture Overview milestone.
>>>>>
>>>>> It was recognized that it is not in final form but would be a good st=
arting point for the architecture overview.
>>>>>
>>>>> Please comment on whether or not this should become a working group d=
ocument.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Steve
>>>>>
>>>>> _______________________________________________
>>>>> Modern mailing list
>>>>> Modern@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/modern
>>>> _______________________________________________
>>>> Modern mailing list
>>>> Modern@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/modern
>>> _______________________________________________
>>> Modern mailing list
>>> Modern@ietf.org
>>> https://www.ietf.org/mailman/listinfo/modern
>> _______________________________________________
>> Modern mailing list
>> Modern@ietf.org
>> https://www.ietf.org/mailman/listinfo/modern
>
>_______________________________________________
>Modern mailing list
>Modern@ietf.org
>https://www.ietf.org/mailman/listinfo/modern


From nobody Mon Dec 14 10:31:33 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94791B2D32 for ; Mon, 14 Dec 2015 10:31:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.276
X-Spam-Level: 
X-Spam-Status: No, score=-0.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6a_TLAXSoLri for ; Mon, 14 Dec 2015 10:31:29 -0800 (PST)
Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D4431B2D28 for ; Mon, 14 Dec 2015 10:31:29 -0800 (PST)
Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id tBEITQgJ018006; Mon, 14 Dec 2015 13:31:27 -0500
Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1yrqn7btcn-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Dec 2015 13:31:27 -0500
Received: from STNTEXMB11.cis.neustar.com ([169.254.1.102]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Mon, 14 Dec 2015 13:31:01 -0500
From: "McGarry, Tom" 
To: "PFAUTZ, PENN L" , "modern@ietf.org" 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHRHl26DyraNZUDF0WIF1b3d5Qwlp7FC3CAgABrkwCABZwMgIAAEsgAgAAjGgD//7V3AA==
Date: Mon, 14 Dec 2015 18:31:01 +0000
Message-ID: 
In-Reply-To: <38726EDA2109264987B45E29E758C4D60592552D@MISOUT7MSGUSRDD.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.2.130206
x-originating-ip: [10.33.205.112]
Content-Type: multipart/alternative; boundary="_000_D29474A832E1Btommcgarryneustarbiz_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-12-14_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310007 definitions=main-1512140310
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 14 Dec 2015 18:31:32 -0000

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

Thanks Penn.

I don't understand your point about numbering vs interconnection.  Is there=
 something in the document you can point to?

Also can you point me to the statements about user and SP roles?

From: , PENN L >
Date: Monday, December 14, 2015 12:57 PM
To: Pierce Gorman >, Steve Donovan >, Modern List >
Subject: Re: [Modern] Problem statement draft as working group document

I find that I need to object as well. It is not numbering that drives inter=
connection so much as interconnection drives numbering. As the evolution of=
 interconnection even as the PSTN migrates to an IP backbone is by no means=
 settled I=92m concerned that we are getting the cart before the horse. I a=
lso object to the conclusory statements about user and service provider rol=
es; I think the picture is more complicated.
I remain sympathetic to the goal of modernizing number administration and r=
outing but the document is problematic for me.

Penn Pfautz
AT&T Global Connection Management


From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com]
Sent: Monday, December 14, 2015 10:52 AM
To: Steve Donovan; modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

If an actual reason is not required I would like to add my vote of dissensi=
on on principal without having to actually read the =93draft-peterson-moder=
n-problems-02=94.  You might recall I argued with the language in the chart=
er but I and others were over-ruled by the Area Directors.

Pierce Gorman

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: December 14, 2015 8:45 AM
To: modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

Eric,

Could you elaborate on why you think the document should not become a worki=
ng group item.
Thanks,

Steve
On 12/10/15 7:05 PM, Eric Burger wrote:

Nah. :-)



On Dec 10, 2015, at 1:40 PM, Steve Donovan  wrote:



There has been no response to this so I'm going to suggest we put a deadlin=
e on opinions.



Please express your opinion on making draft-peterson-modern-problems-02 a w=
orking group document before Thursday, December 17th.



It is important that anyone who supports the promotion of the document also=
 express their opinion.



Thanks,



Steve



On 11/13/15 3:53 PM, Steve Donovan wrote:

All,



During the IETF94 MODERN WG meeting there was consensus that draft-peterson=
-modern-problems-02 be accepted as a working group document.  This would be=
 to address the architecture Architecture Overview milestone.



It was recognized that it is not in final form but would be a good starting=
 point for the architecture overview.



Please comment on whether or not this should become a working group documen=
t.



Regards,



Steve



_______________________________________________

Modern mailing list

Modern@ietf.org

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



_______________________________________________

Modern mailing list

Modern@ietf.org

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





_______________________________________________

Modern mailing list

Modern@ietf.org

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


________________________________

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_D29474A832E1Btommcgarryneustarbiz_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <8CFC93218675E44EACDFFCCB13AE07A8@neustar.biz>
Content-Transfer-Encoding: quoted-printable







Thanks Penn.  







I don't understand your point about numbering vs interconnection. &nbs=
p;Is there something in the document you can point to?







Also can you point me to the statements about user and SP roles?  =
; 









From: <PFAUTZ>, PENN L <pp3129@att.com>

Date: Monday, December 14, 2015 12:=
57 PM

To: Pierce Gorman <Pierce.Gorman@sprint.com>, Steve Dono=
van <srdonovan@usdonovans.co=
m>, Modern List <modern@ietf.o=
rg>

Subject: Re: [Modern] Problem state=
ment draft as working group document

















I find that I need to object as we=
ll. It is not numbering that drives interconnection so much as interconnect=
ion drives numbering. As the evolution
 of interconnection even as the PSTN migrates to an IP backbone is by no me=
ans settled I=92m concerned that we are getting the cart before the horse. =
I also object to the conclusory statements about user and service provider =
roles; I think the picture is more
 complicated.


I remain sympathetic to the goal o=
f modernizing number administration and routing but the document is problem=
atic for me.


 


Penn Pfautz


AT&T Global Connection Managem=
ent


 


 






From: Gorman, =
Pierce A [CTO] [mailto:Pierce.G=
orman@sprint.com]


Sent: Monday, December 14, 2015 10:52 AM

To: Steve Donovan; modern@ietf.or=
g

Subject: Re: [Modern] Problem statement draft as working group docum=
ent






 


If an actual reason is not required I =
would like to add my vote of dissension on principal without having to actu=
ally read the =93draft-peterson-modern-problems-02=94.=
 
 You might recall I argued with the language in the charter but I and other=
s were over-ruled by the Area Directors.


 


Pierce Gorman


 






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

Sent: December 14, 2015 8:45 AM

To: modern@ietf.org

Subject: Re: [Modern] Problem statement draft as working group docum=
ent






 


Eric,



Could you elaborate on why you think the document should not become a worki=
ng group item.


Thanks,



Steve




On 12/10/15 7:05 PM, Eric Burger wrote:





Nah. :-)


 




On Dec 10, 2015, at 1:40 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 


There has been no response to this so I'm going to suggest we put a de=
adline on opinions.


 


Please express your opinion on making draft-peterson-modern-problems-0=
2 a working group document before Thursday, December 17th.


 


It is important that anyone who supports the promotion of the document=
 also express their opinion.


 


Thanks,


 


Steve


 


On 11/13/15 3:53 PM, Steve Donovan wrote:




All,


 


During the IETF94 MODERN WG meeting there was consensus that draft-pet=
erson-modern-problems-02 be accepted as a working group document.  Thi=
s would be to address the architecture Architecture Overview milestone.


 


It was recognized that it is not in final form but would be a good sta=
rting point for the architecture overview.


 


Please comment on whether or not this should become a working group do=
cument.


 


Regards,


 


Steve


 


_______________________________________________


Modern mailing list


Modern@ietf.org

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




 


_______________________________________________


Modern mailing list


Modern@ietf.org

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




 









_______________________________________________


Modern mailing list


Modern@ietf.org

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




 


 










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


From nobody Mon Dec 14 10:44:58 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112B41B2D60 for ; Mon, 14 Dec 2015 10:44:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.276
X-Spam-Level: 
X-Spam-Status: No, score=-0.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Doo0qkXJlak3 for ; Mon, 14 Dec 2015 10:44:54 -0800 (PST)
Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 57A461B2D5C for ; Mon, 14 Dec 2015 10:44:54 -0800 (PST)
Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id tBEIhvIf013122; Mon, 14 Dec 2015 13:44:49 -0500
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 1yrdr40c9y-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);  Mon, 14 Dec 2015 13:44:48 -0500
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 tBEIilkX030495; Mon, 14 Dec 2015 13:44:48 -0500
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 tBEIidwd030342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Dec 2015 13:44:42 -0500
Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Mon, 14 Dec 2015 18:44:32 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.78]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0248.002; Mon, 14 Dec 2015 13:44:32 -0500
From: "DOLLY, MARTIN C" 
To: "McGarry, Tom" 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHRNod+t9tG2eQFXECnCpoLN3xbKp7KwzDQgABevID//6/1GQ==
Date: Mon, 14 Dec 2015 18:44:31 +0000
Message-ID: <83ABC2CA-7EE2-4C3F-A759-C7A97EDDF1B2@att.com>
References: <38726EDA2109264987B45E29E758C4D60592552D@MISOUT7MSGUSRDD.ITServices.sbc.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_83ABC2CA7EE24C3FA759C7A97EDDF1B2attcom_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-12-14_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310007 definitions=main-1512140316
Archived-At: 
Cc: "modern@ietf.org" , "PFAUTZ, PENN L" 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 14 Dec 2015 18:44:57 -0000

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

Number assignment to users has been an is from day 1.
If there was no Interconnection, none of this would be relevant

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: 609-903-3360
Email: md3135@att.com

On Dec 14, 2015, at 1:31 PM, McGarry, Tom > wrote:

Thanks Penn.

I don't understand your point about numbering vs interconnection.  Is there=
 something in the document you can point to?

Also can you point me to the statements about user and SP roles?

From: , PENN L >
Date: Monday, December 14, 2015 12:57 PM
To: Pierce Gorman >, Steve Donovan >, Modern List >
Subject: Re: [Modern] Problem statement draft as working group document

I find that I need to object as well. It is not numbering that drives inter=
connection so much as interconnection drives numbering. As the evolution of=
 interconnection even as the PSTN migrates to an IP backbone is by no means=
 settled I=92m concerned that we are getting the cart before the horse. I a=
lso object to the conclusory statements about user and service provider rol=
es; I think the picture is more complicated.
I remain sympathetic to the goal of modernizing number administration and r=
outing but the document is problematic for me.

Penn Pfautz
AT&T Global Connection Management


From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com]
Sent: Monday, December 14, 2015 10:52 AM
To: Steve Donovan; modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

If an actual reason is not required I would like to add my vote of dissensi=
on on principal without having to actually read the =93draft-peterson-moder=
n-problems-02=94.  You might recall I argued with the language in the chart=
er but I and others were over-ruled by the Area Directors.

Pierce Gorman

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: December 14, 2015 8:45 AM
To: modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

Eric,

Could you elaborate on why you think the document should not become a worki=
ng group item.
Thanks,

Steve
On 12/10/15 7:05 PM, Eric Burger wrote:

Nah. :-)



On Dec 10, 2015, at 1:40 PM, Steve Donovan  wrote:



There has been no response to this so I'm going to suggest we put a deadlin=
e on opinions.



Please express your opinion on making draft-peterson-modern-problems-02 a w=
orking group document before Thursday, December 17th.



It is important that anyone who supports the promotion of the document also=
 express their opinion.



Thanks,



Steve



On 11/13/15 3:53 PM, Steve Donovan wrote:

All,



During the IETF94 MODERN WG meeting there was consensus that draft-peterson=
-modern-problems-02 be accepted as a working group document.  This would be=
 to address the architecture Architecture Overview milestone.



It was recognized that it is not in final form but would be a good starting=
 point for the architecture overview.



Please comment on whether or not this should become a working group documen=
t.



Regards,



Steve



_______________________________________________

Modern mailing list

Modern@ietf.org

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



_______________________________________________

Modern mailing list

Modern@ietf.org

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





_______________________________________________

Modern mailing list

Modern@ietf.org

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


________________________________

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

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







Number assignment to users has been an is from day 1. 


If there was no Interconnection, none of thi=
s would be relevant 



Martin C Dolly

Lead Member of Technical Staff


Core & Government/Regulatory Standards 


AT&T


Cell: 609-903-3360







On Dec 14, 2015, at 1:31 PM, McGarry, Tom <Tom.McGarry@neustar.biz> wrote:










Thanks Penn.  







I don't understand your point about numbering vs interconnection. &nbs=
p;Is there something in the document you can point to?







Also can you point me to the statements about user and SP roles?  =
; 









From: <PFAUTZ>, PENN L <pp3129@att.com>

Date: Monday, December 14, 2015 12:=
57 PM

To: Pierce Gorman <Pierce.Gorman@sprint.com>, Steve Dono=
van <srdonovan@usdonovans.co=
m>, Modern List <modern@ietf.o=
rg>

Subject: Re: [Modern] Problem state=
ment draft as working group document

















I find that I need to object as we=
ll. It is not numbering that drives interconnection so much as interconnect=
ion drives numbering. As the evolution
 of interconnection even as the PSTN migrates to an IP backbone is by no me=
ans settled I=92m concerned that we are getting the cart before the horse. =
I also object to the conclusory statements about user and service provider =
roles; I think the picture is more
 complicated.


I remain sympathetic to the goal o=
f modernizing number administration and routing but the document is problem=
atic for me.


 


Penn Pfautz


AT&T Global Connection Managem=
ent


 


 






From: Gorman, =
Pierce A [CTO] [mailto:Pierce.G=
orman@sprint.com]


Sent: Monday, December 14, 2015 10:52 AM

To: Steve Donovan; modern@ietf.or=
g

Subject: Re: [Modern] Problem statement draft as working group docum=
ent






 


If an actual reason is not required I =
would like to add my vote of dissension on principal without having to actu=
ally read the =93draft-peterson-modern-problems-02=94.=
 
 You might recall I argued with the language in the charter but I and other=
s were over-ruled by the Area Directors.


 


Pierce Gorman


 






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

Sent: December 14, 2015 8:45 AM

To: modern@ietf.org

Subject: Re: [Modern] Problem statement draft as working group docum=
ent






 


Eric,



Could you elaborate on why you think the document should not become a worki=
ng group item.


Thanks,



Steve




On 12/10/15 7:05 PM, Eric Burger wrote:





Nah. :-)


 




On Dec 10, 2015, at 1:40 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 


There has been no response to this so I'm going to suggest we put a de=
adline on opinions.


 


Please express your opinion on making draft-peterson-modern-problems-0=
2 a working group document before Thursday, December 17th.


 


It is important that anyone who supports the promotion of the document=
 also express their opinion.


 


Thanks,


 


Steve


 


On 11/13/15 3:53 PM, Steve Donovan wrote:




All,


 


During the IETF94 MODERN WG meeting there was consensus that draft-pet=
erson-modern-problems-02 be accepted as a working group document.  Thi=
s would be to address the architecture Architecture Overview milestone.


 


It was recognized that it is not in final form but would be a good sta=
rting point for the architecture overview.


 


Please comment on whether or not this should become a working group do=
cument.


 


Regards,


 


Steve


 


_______________________________________________


Modern mailing list


Modern@ietf.org

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




 


_______________________________________________


Modern mailing list


Modern@ietf.org

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




 









_______________________________________________


Modern mailing list


Modern@ietf.org

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




 


 










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








--_000_83ABC2CA7EE24C3FA759C7A97EDDF1B2attcom_--


From nobody Mon Dec 14 10:49: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 5271F1B2D71 for ; Mon, 14 Dec 2015 10:49:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.277
X-Spam-Level: 
X-Spam-Status: No, score=-0.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7qaLzMD9MxZ for ; Mon, 14 Dec 2015 10:49:37 -0800 (PST)
Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73FE81B2D70 for ; Mon, 14 Dec 2015 10:49:37 -0800 (PST)
Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id tBEIlbg4013548; Mon, 14 Dec 2015 13:49:35 -0500
Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1yrqn7kut5-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Dec 2015 13:49:34 -0500
Received: from STNTEXMB11.cis.neustar.com ([169.254.1.102]) by stntexhc10.cis.neustar.com ([169.254.4.121]) with mapi id 14.03.0158.001; Mon, 14 Dec 2015 13:49:32 -0500
From: "McGarry, Tom" 
To: "DOLLY, MARTIN C" , "modern@ietf.org" 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHRHl26DyraNZUDF0WIF1b3d5Qwlp7FC3CAgABrkwCABZwMgIAAEsgAgAAjGgD//7V3AIAAV56A//+tkAA=
Date: Mon, 14 Dec 2015 18:49:31 +0000
Message-ID: 
In-Reply-To: <83ABC2CA-7EE2-4C3F-A759-C7A97EDDF1B2@att.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.2.130206
x-originating-ip: [10.33.205.112]
Content-Type: multipart/alternative; boundary="_000_D29478FA32E2Dtommcgarryneustarbiz_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-12-14_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310007 definitions=main-1512140316
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 14 Dec 2015 18:49:40 -0000

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

Ok, I'm aware that some people do not like the concept of number assignment=
 to users.

But there is interconnection, does that mean this is relevant?

From: , Martin Dolly >
Date: Monday, December 14, 2015 1:44 PM
To: Tom Mcgarry >
Cc: "PFAUTZ, PENN L" >, Modern List <=
modern@ietf.org>
Subject: Re: [Modern] Problem statement draft as working group document

Number assignment to users has been an is from day 1.
If there was no Interconnection, none of this would be relevant

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: 609-903-3360
Email: md3135@att.com

On Dec 14, 2015, at 1:31 PM, McGarry, Tom > wrote:

Thanks Penn.

I don't understand your point about numbering vs interconnection.  Is there=
 something in the document you can point to?

Also can you point me to the statements about user and SP roles?

From: , PENN L >
Date: Monday, December 14, 2015 12:57 PM
To: Pierce Gorman >, Steve Donovan >, Modern List >
Subject: Re: [Modern] Problem statement draft as working group document

I find that I need to object as well. It is not numbering that drives inter=
connection so much as interconnection drives numbering. As the evolution of=
 interconnection even as the PSTN migrates to an IP backbone is by no means=
 settled I=92m concerned that we are getting the cart before the horse. I a=
lso object to the conclusory statements about user and service provider rol=
es; I think the picture is more complicated.
I remain sympathetic to the goal of modernizing number administration and r=
outing but the document is problematic for me.

Penn Pfautz
AT&T Global Connection Management


From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com]
Sent: Monday, December 14, 2015 10:52 AM
To: Steve Donovan; modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

If an actual reason is not required I would like to add my vote of dissensi=
on on principal without having to actually read the =93draft-peterson-moder=
n-problems-02=94.  You might recall I argued with the language in the chart=
er but I and others were over-ruled by the Area Directors.

Pierce Gorman

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: December 14, 2015 8:45 AM
To: modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

Eric,

Could you elaborate on why you think the document should not become a worki=
ng group item.
Thanks,

Steve
On 12/10/15 7:05 PM, Eric Burger wrote:

Nah. :-)



On Dec 10, 2015, at 1:40 PM, Steve Donovan  wrote:



There has been no response to this so I'm going to suggest we put a deadlin=
e on opinions.



Please express your opinion on making draft-peterson-modern-problems-02 a w=
orking group document before Thursday, December 17th.



It is important that anyone who supports the promotion of the document also=
 express their opinion.



Thanks,



Steve



On 11/13/15 3:53 PM, Steve Donovan wrote:

All,



During the IETF94 MODERN WG meeting there was consensus that draft-peterson=
-modern-problems-02 be accepted as a working group document.  This would be=
 to address the architecture Architecture Overview milestone.



It was recognized that it is not in final form but would be a good starting=
 point for the architecture overview.



Please comment on whether or not this should become a working group documen=
t.



Regards,



Steve



_______________________________________________

Modern mailing list

Modern@ietf.org

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



_______________________________________________

Modern mailing list

Modern@ietf.org

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





_______________________________________________

Modern mailing list

Modern@ietf.org

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


________________________________

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

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







Ok, I'm aware that some people do not like the concept of number assig=
nment to users.  







But there is interconnection, does that mean this is relevant?  <=
/div>








From: <DOLLY>, Martin Dolly &=
lt;md3135@att.com>

Date: Monday, December 14, 2015 1:4=
4 PM

To: Tom Mcgarry <tom.mcgarry@neustar.biz>

Cc: "PFAUTZ, PENN L" <=
pp3129@att.com>, Modern List <<=
a href=3D"mailto:modern@ietf.org">modern@ietf.org>

Subject: Re: [Modern] Problem state=
ment draft as working group document













Number assignment to users has been an is from day 1. 


If there was no Interconnection, none of thi=
s would be relevant 



Martin C Dolly

Lead Member of Technical Staff


Core & Government/Regulatory Standards 


AT&T


Cell: 609-903-3360







On Dec 14, 2015, at 1:31 PM, McGarry, Tom <Tom.McGarry@neustar.biz> wrote:










Thanks Penn.  







I don't understand your point about numbering vs interconnection. &nbs=
p;Is there something in the document you can point to?







Also can you point me to the statements about user and SP roles?  =
; 









From: <PFAUTZ>, PENN L <pp3129@att.com>

Date: Monday, December 14, 2015 12:=
57 PM

To: Pierce Gorman <Pierce.Gorman@sprint.com>, Steve Dono=
van <srdonovan@usdonovans.co=
m>, Modern List <modern@ietf.o=
rg>

Subject: Re: [Modern] Problem state=
ment draft as working group document

















I find that I need to object as we=
ll. It is not numbering that drives interconnection so much as interconnect=
ion drives numbering. As the evolution
 of interconnection even as the PSTN migrates to an IP backbone is by no me=
ans settled I=92m concerned that we are getting the cart before the horse. =
I also object to the conclusory statements about user and service provider =
roles; I think the picture is more
 complicated.


I remain sympathetic to the goal o=
f modernizing number administration and routing but the document is problem=
atic for me.


 


Penn Pfautz


AT&T Global Connection Managem=
ent


 


 






From: Gorman, =
Pierce A [CTO] [mailto:Pierce.G=
orman@sprint.com]


Sent: Monday, December 14, 2015 10:52 AM

To: Steve Donovan; modern@ietf.or=
g

Subject: Re: [Modern] Problem statement draft as working group docum=
ent






 


If an actual reason is not required I =
would like to add my vote of dissension on principal without having to actu=
ally read the =93draft-peterson-modern-problems-02=94.=
 
 You might recall I argued with the language in the charter but I and other=
s were over-ruled by the Area Directors.


 


Pierce Gorman


 






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

Sent: December 14, 2015 8:45 AM

To: modern@ietf.org

Subject: Re: [Modern] Problem statement draft as working group docum=
ent






 


Eric,



Could you elaborate on why you think the document should not become a worki=
ng group item.


Thanks,



Steve




On 12/10/15 7:05 PM, Eric Burger wrote:





Nah. :-)


 




On Dec 10, 2015, at 1:40 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 


There has been no response to this so I'm going to suggest we put a de=
adline on opinions.


 


Please express your opinion on making draft-peterson-modern-problems-0=
2 a working group document before Thursday, December 17th.


 


It is important that anyone who supports the promotion of the document=
 also express their opinion.


 


Thanks,


 


Steve


 


On 11/13/15 3:53 PM, Steve Donovan wrote:




All,


 


During the IETF94 MODERN WG meeting there was consensus that draft-pet=
erson-modern-problems-02 be accepted as a working group document.  Thi=
s would be to address the architecture Architecture Overview milestone.


 


It was recognized that it is not in final form but would be a good sta=
rting point for the architecture overview.


 


Please comment on whether or not this should become a working group do=
cument.


 


Regards,


 


Steve


 


_______________________________________________


Modern mailing list


Modern@ietf.org

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




 


_______________________________________________


Modern mailing list


Modern@ietf.org

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




 









_______________________________________________


Modern mailing list


Modern@ietf.org

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




 


 










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













--_000_D29478FA32E2Dtommcgarryneustarbiz_--


From nobody Mon Dec 14 10:52:29 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B201B2D73 for ; Mon, 14 Dec 2015 10:52:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_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 LYj-H1uqUq6H for ; Mon, 14 Dec 2015 10:52:21 -0800 (PST)
Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id E3F811B2D47 for ; Mon, 14 Dec 2015 10:52:20 -0800 (PST)
Received: (qmail 18996 invoked by uid 0); 14 Dec 2015 18:52:17 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy1.mail.unifiedlayer.com with SMTP; 14 Dec 2015 18:52:17 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with  id tWY61r00z1MNPNq01WY9ve; Mon, 14 Dec 2015 11:32:16 -0700
X-Authority-Analysis: v=2.1 cv=dqRIVTQ4 c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=P34Qx31D9VQA:10 a=wUQvQvOEmiQA:10 a=jqBRFv0mrdUA:10 a=PeFO9FbFhS32YxYntvkA:9 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=izV7ms69AAAA:8 a=yakATiurAAAA:8 a=OnrPcLhIkEmpnJkY_b4A:9 a=eO2Wx6vk0eRmTIwy:21 a=kX9MQ3RtqP1hKWPV:21 a=QEXdDO2ut3YA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=DCAd3nRkLH0gjkG_:21 a=rYh-eNsHXI1Re666:21 a=rmArzMZCZPtfEKL1:21 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us;  s=default;  h=Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=8PfWcMf+1fOEVHgtWtEGILre/aBGQuD8JEN4ughDo0A=;  b=bQ55SxII08CdVXT9IqGIxPa8qZ6UNDKsqRkcIVXy3N2K9nL6GZT4vuditvpiSscIGzDmxtdZxLe/rWjZodeA9u8UYvh+KYvTiveDwErqbLOpUALV2vtsIilnyFpywlLu;
Received: from [69.241.19.12] (port=6641 helo=[10.36.94.120]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1a8Xuq-0005Wh-5i; Mon, 14 Dec 2015 11:32:08 -0700
User-Agent: Microsoft-MacOutlook/0.0.0.151105
Date: Mon, 14 Dec 2015 13:32:00 -0500
From: Richard Shockey 
To: "PFAUTZ, PENN L" , "Gorman, Pierce A [CTO]" , Steve Donovan , "modern@ietf.org" 
Message-ID: 
Thread-Topic: [Modern] Problem statement draft as working group document
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com>  <566ED5E3.9020203@usdonovans.com>  <38726EDA2109264987B45E29E758C4D60592552D@MISOUT7MSGUSRDD.ITServices.sbc.com>
In-Reply-To: <38726EDA2109264987B45E29E758C4D60592552D@MISOUT7MSGUSRDD.ITServices.sbc.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3532944727_705491793"
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 69.241.19.12 authed with richard+shockey.us}
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 14 Dec 2015 18:52:27 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3532944727_705491793
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable



From:  Modern  on behalf of "PFAUTZ, PENN L" 
Date:  Monday, December 14, 2015 at 12:57 PM
To:  "Pierce.Gorman@sprint.com" , Steve Donovan <=
srdonovan@usdonovans.com>, "modern@ietf.org" 
Subject:  Re: [Modern] Problem statement draft as working group document

I find that I need to object as well. It is not numbering that drives inter=
connection so much as interconnection drives numbering. As the evolution of =
interconnection even as the PSTN migrates to an IP backbone is by no means s=
ettled I=E2=80=99m concerned that we are getting the cart before the horse. I also=
 object to the conclusory statements about user and service provider roles; =
I think the picture is more complicated.

I remain sympathetic to the goal of modernizing number administration and r=
outing but the document is problematic for me.



RS> +1  Very well said


=20

Penn Pfautz

AT&T Global Connection Management

=20

=20

From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com]=20
Sent: Monday, December 14, 2015 10:52 AM
To: Steve Donovan; modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

=20

If an actual reason is not required I would like to add my vote of dissensi=
on on principal without having to actually read the =E2=80=9Cdraft-peterson-modern=
-problems-02=E2=80=9D.  You might recall I argued with the language in the charter=
 but I and others were over-ruled by the Area Directors.

=20

Pierce Gorman

=20

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: December 14, 2015 8:45 AM
To: modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

=20

Eric,

Could you elaborate on why you think the document should not become a worki=
ng group item.

Thanks,

Steve

On 12/10/15 7:05 PM, Eric Burger wrote:
Nah. :-)
=20
On Dec 10, 2015, at 1:40 PM, Steve Donovan  wrote=
:
=20
There has been no response to this so I'm going to suggest we put a deadlin=
e on opinions.
=20
Please express your opinion on making draft-peterson-modern-problems-02 a w=
orking group document before Thursday, December 17th.
=20
It is important that anyone who supports the promotion of the document also=
 express their opinion.
=20
Thanks,
=20
Steve
=20
On 11/13/15 3:53 PM, Steve Donovan wrote:
All,
=20
During the IETF94 MODERN WG meeting there was consensus that draft-peterson=
-modern-problems-02 be accepted as a working group document.  This would be =
to address the architecture Architecture Overview milestone.
=20
It was recognized that it is not in final form but would be a good starting=
 point for the architecture overview.
=20
Please comment on whether or not this should become a working group documen=
t.
=20
Regards,
=20
Steve
=20
_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern
=20
_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern
=20


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

=20


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

--B_3532944727_705491793
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable




From:  Modern <modern-bounces@ietf.org> on behal=
f of "PFAUTZ, PENN L" <pp3129@att.com=
>
Date:  Monday, December 14, 20=
15 at 12:57 PM
To:  "Pierce.Gorman@sprint.com" <Pierce.Gorman@sprint.com>, Steve Donovan =
<srdonovan@usdonovans.com&g=
t;, "modern@ietf.org" <modern@ietf.org>
Subject:  Re: [Modern] Problem statement draft as working group doc=
ument

I find that I need to object as well. It is not numbering that drives int=
erconnection so much as interconnection drives numbering. As the evolution o=
f interconnection
 even as the PSTN migrates to an IP backbone is by no means settled I’=
;m concerned that we are getting the cart before the horse. I also object to=
 the conclusory statements about user and service provider roles; I think th=
e picture is more complicated.
I remain sympathetic to the goal of modernizing number administrati=
on and routing but the document is problematic for me.


RS> +1  Very well s=
aid


<=
p class=3D"MsoNormal"> 
Penn Pfautz
AT&T Global Connection Management
 
 
From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com]

Sent: Monday, December 14, 2015 10:52 AM
To: Steve Don=
ovan; modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document<=
/span>
 
If an actual reason is not required I would like to add m=
y vote of dissension on principal without having to actually read the “=
;draft-peterson-modern-problems-02”. 
 You might recall I argued with the language in the charter but I and other=
s were over-ruled by the Area Directors.
 
=
Pierce Gorman
 =
;
From: Modern [mai=
lto:modern-bounces@ietf.org]
On Behalf Of Steve Donovan
Sent: December 14, 2015 8:45 AM=

To: modern@ietf.org
Su=
bject: Re: [Modern] Problem statement draft as working group document
 
Eric,


Could you elaborate on why you think the document should not become a worki=
ng group item.
Thanks,


Steve
On 12/10/15 7:05 PM, Eric Bur=
ger wrote:
Nah. :-)
 
On Dec 10, 2015, at =
1:40 PM, Steve Donovan <srdonov=
an@usdonovans.com> wrote:
 
There has been no response to this so I'm going to suggest we put a de=
adline on opinions.
 
Please =
express your opinion on making draft-peterson-modern-problems-02 a working g=
roup document before Thursday, December 17th.
&nbs=
p;
It is important that anyone who supports the promotion of=
 the document also express their opinion.
 
Thanks,
 
Stev=
e
 
On 11/13/15 3:53 PM, Stev=
e Donovan wrote:
All,
 
Dur=
ing the IETF94 MODERN WG meeting there was consensus that draft-peterson-mod=
ern-problems-02 be accepted as a working group document.  This would be=
 to address the architecture Architecture Overview milestone.
 
It was recognized that it is not in final=
 form but would be a good starting point for the architecture overview.=

 
Please comment on whether or no=
t this should become a working group document.
&nb=
sp;
Regards,
 
Steve
 
___________________=
____________________________
Modern mailing list
Modern@ietf.org
https://=
www.ietf.org/mailman/listinfo/modern
<=
o:p> 
_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/=
modern
 


______=
_________________________________________
Modern mailin=
g 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 t=
he intended recipient, please contact the sender and delete all copies of th=
e message.
=


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


--B_3532944727_705491793--



From nobody Mon Dec 14 10:53:04 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90AB81B2D76 for ; Mon, 14 Dec 2015 10:53:03 -0800 (PST)
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 KTLg9wb2W3Oe for ; Mon, 14 Dec 2015 10:53:02 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C57C1B2D74 for ; Mon, 14 Dec 2015 10:53:02 -0800 (PST)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tBEIqt8X014469 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 14 Dec 2015 12:53:00 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
To: Steve Donovan , modern@ietf.org
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com>
From: Adam Roach 
Message-ID: <566F1005.4050302@nostrum.com>
Date: Mon, 14 Dec 2015 12:52:53 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <5669C701.3060604@usdonovans.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 14 Dec 2015 18:53:03 -0000

On 12/10/15 12:40, Steve Donovan wrote:
> There has been no response to this so I'm going to suggest we put a 
> deadline on opinions.
>
> Please express your opinion on making 
> draft-peterson-modern-problems-02 a working group document before 
> Thursday, December 17th.
>
> It is important that anyone who supports the promotion of the document 
> also express their opinion.

I think this document is a good starting point for outlining the basic 
shape of the problem and the use cases MODERN is intended to address.

I'll note that on-list objections so far seem to be attempting to 
re-litigate the formation of the working group rather than making 
progress towards its milestones. As has been long established (at least 
since the 2002 formation of XMPP), the decision to work on a problem in 
the IETF is based on the following criteria: "is it technically 
credible, are people willing to work on it, are people willing to use 
it?" And, in particular: "we should be deciding things based on the 
number of folks who want to do things, not the number opposed."

In terms of considering adoption of this specific document, I think we 
need to be careful to parse out objections to its contents versus 
objections to MODERN's very existence. So far, I have seen no on-list 
objections that fall in the first category.

/a


From nobody Mon Dec 14 11:00:39 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854021B2D8D for ; Mon, 14 Dec 2015 11:00:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.276
X-Spam-Level: 
X-Spam-Status: No, score=-0.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XJFZZVa2l9R for ; Mon, 14 Dec 2015 11:00:31 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 13C5E1B2D96 for ; Mon, 14 Dec 2015 11:00:30 -0800 (PST)
Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id tBEIhtXW021493; Mon, 14 Dec 2015 14:00:29 -0500
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by mx0a-00191d01.pphosted.com with ESMTP id 1ystswemmr-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);  Mon, 14 Dec 2015 14:00:29 -0500
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 tBEJ0RuW021671; Mon, 14 Dec 2015 14:00:28 -0500
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 tBEJ0JFj021510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Dec 2015 14:00:23 -0500
Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Mon, 14 Dec 2015 19:00:00 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.78]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0248.002; Mon, 14 Dec 2015 13:59:59 -0500
From: "DOLLY, MARTIN C" 
To: "McGarry, Tom" 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHRNod+t9tG2eQFXECnCpoLN3xbKp7KwzDQgABevID//6/1GYAAVTeA//+vG4w=
Date: Mon, 14 Dec 2015 18:59:59 +0000
Message-ID: 
References: <83ABC2CA-7EE2-4C3F-A759-C7A97EDDF1B2@att.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_C73EA6BF72674878B468233B418AC846attcom_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-12-14_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310007 definitions=main-1512140316
Archived-At: 
Cc: "modern@ietf.org" 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 14 Dec 2015 19:00:37 -0000

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

It would be nice to hear a regulator point of view.
The FCC assigns numbers to entities (eg. SP) that they can regulate and if =
there is misbehavior punish. This point has been made over and over again

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: 609-903-3360
Email: md3135@att.com

On Dec 14, 2015, at 1:49 PM, McGarry, Tom > wrote:

Ok, I'm aware that some people do not like the concept of number assignment=
 to users.

But there is interconnection, does that mean this is relevant?

From: , Martin Dolly >
Date: Monday, December 14, 2015 1:44 PM
To: Tom Mcgarry >
Cc: "PFAUTZ, PENN L" >, Modern List <=
modern@ietf.org>
Subject: Re: [Modern] Problem statement draft as working group document

Number assignment to users has been an is from day 1.
If there was no Interconnection, none of this would be relevant

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: 609-903-3360
Email: md3135@att.com

On Dec 14, 2015, at 1:31 PM, McGarry, Tom > wrote:

Thanks Penn.

I don't understand your point about numbering vs interconnection.  Is there=
 something in the document you can point to?

Also can you point me to the statements about user and SP roles?

From: , PENN L >
Date: Monday, December 14, 2015 12:57 PM
To: Pierce Gorman >, Steve Donovan >, Modern List >
Subject: Re: [Modern] Problem statement draft as working group document

I find that I need to object as well. It is not numbering that drives inter=
connection so much as interconnection drives numbering. As the evolution of=
 interconnection even as the PSTN migrates to an IP backbone is by no means=
 settled I=92m concerned that we are getting the cart before the horse. I a=
lso object to the conclusory statements about user and service provider rol=
es; I think the picture is more complicated.
I remain sympathetic to the goal of modernizing number administration and r=
outing but the document is problematic for me.

Penn Pfautz
AT&T Global Connection Management


From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com]
Sent: Monday, December 14, 2015 10:52 AM
To: Steve Donovan; modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

If an actual reason is not required I would like to add my vote of dissensi=
on on principal without having to actually read the =93draft-peterson-moder=
n-problems-02=94.  You might recall I argued with the language in the chart=
er but I and others were over-ruled by the Area Directors.

Pierce Gorman

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: December 14, 2015 8:45 AM
To: modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

Eric,

Could you elaborate on why you think the document should not become a worki=
ng group item.
Thanks,

Steve
On 12/10/15 7:05 PM, Eric Burger wrote:

Nah. :-)



On Dec 10, 2015, at 1:40 PM, Steve Donovan  wrote:



There has been no response to this so I'm going to suggest we put a deadlin=
e on opinions.



Please express your opinion on making draft-peterson-modern-problems-02 a w=
orking group document before Thursday, December 17th.



It is important that anyone who supports the promotion of the document also=
 express their opinion.



Thanks,



Steve



On 11/13/15 3:53 PM, Steve Donovan wrote:

All,



During the IETF94 MODERN WG meeting there was consensus that draft-peterson=
-modern-problems-02 be accepted as a working group document.  This would be=
 to address the architecture Architecture Overview milestone.



It was recognized that it is not in final form but would be a good starting=
 point for the architecture overview.



Please comment on whether or not this should become a working group documen=
t.



Regards,



Steve



_______________________________________________

Modern mailing list

Modern@ietf.org

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



_______________________________________________

Modern mailing list

Modern@ietf.org

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





_______________________________________________

Modern mailing list

Modern@ietf.org

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


________________________________

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

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







It would be nice to hear a regulator point of view. 


The FCC assigns numbers to entities (eg. SP)=
 that they can regulate and if there is misbehavior punish. This point has =
been made over and over again



Martin C Dolly

Lead Member of Technical Staff


Core & Government/Regulatory Standards 


AT&T


Cell: 609-903-3360







On Dec 14, 2015, at 1:49 PM, McGarry, Tom <Tom.McGarry@neustar.biz> wrote:










Ok, I'm aware that some people do not like the concept of number assig=
nment to users.  







But there is interconnection, does that mean this is relevant?  <=
/div>








From: <DOLLY>, Martin Dolly &=
lt;md3135@att.com>

Date: Monday, December 14, 2015 1:4=
4 PM

To: Tom Mcgarry <tom.mcgarry@neustar.biz>

Cc: "PFAUTZ, PENN L" <=
pp3129@att.com>, Modern List <<=
a href=3D"mailto:modern@ietf.org">modern@ietf.org>

Subject: Re: [Modern] Problem state=
ment draft as working group document













Number assignment to users has been an is from day 1. 


If there was no Interconnection, none of thi=
s would be relevant 



Martin C Dolly

Lead Member of Technical Staff


Core & Government/Regulatory Standards 


AT&T


Cell: 609-903-3360







On Dec 14, 2015, at 1:31 PM, McGarry, Tom <Tom.McGarry@neustar.biz> wrote:










Thanks Penn.  







I don't understand your point about numbering vs interconnection. &nbs=
p;Is there something in the document you can point to?







Also can you point me to the statements about user and SP roles?  =
; 









From: <PFAUTZ>, PENN L <pp3129@att.com>

Date: Monday, December 14, 2015 12:=
57 PM

To: Pierce Gorman <Pierce.Gorman@sprint.com>, Steve Dono=
van <srdonovan@usdonovans.co=
m>, Modern List <modern@ietf.o=
rg>

Subject: Re: [Modern] Problem state=
ment draft as working group document

















I find that I need to object as we=
ll. It is not numbering that drives interconnection so much as interconnect=
ion drives numbering. As the evolution
 of interconnection even as the PSTN migrates to an IP backbone is by no me=
ans settled I=92m concerned that we are getting the cart before the horse. =
I also object to the conclusory statements about user and service provider =
roles; I think the picture is more
 complicated.


I remain sympathetic to the goal o=
f modernizing number administration and routing but the document is problem=
atic for me.


 


Penn Pfautz


AT&T Global Connection Managem=
ent


 


 






From: Gorman, =
Pierce A [CTO] [mailto:Pierce.G=
orman@sprint.com]


Sent: Monday, December 14, 2015 10:52 AM

To: Steve Donovan; modern@ietf.or=
g

Subject: Re: [Modern] Problem statement draft as working group docum=
ent






 


If an actual reason is not required I =
would like to add my vote of dissension on principal without having to actu=
ally read the =93draft-peterson-modern-problems-02=94.=
 
 You might recall I argued with the language in the charter but I and other=
s were over-ruled by the Area Directors.


 


Pierce Gorman


 






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

Sent: December 14, 2015 8:45 AM

To: modern@ietf.org

Subject: Re: [Modern] Problem statement draft as working group docum=
ent






 


Eric,



Could you elaborate on why you think the document should not become a worki=
ng group item.


Thanks,



Steve




On 12/10/15 7:05 PM, Eric Burger wrote:





Nah. :-)


 




On Dec 10, 2015, at 1:40 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 


There has been no response to this so I'm going to suggest we put a de=
adline on opinions.


 


Please express your opinion on making draft-peterson-modern-problems-0=
2 a working group document before Thursday, December 17th.


 


It is important that anyone who supports the promotion of the document=
 also express their opinion.


 


Thanks,


 


Steve


 


On 11/13/15 3:53 PM, Steve Donovan wrote:




All,


 


During the IETF94 MODERN WG meeting there was consensus that draft-pet=
erson-modern-problems-02 be accepted as a working group document.  Thi=
s would be to address the architecture Architecture Overview milestone.


 


It was recognized that it is not in final form but would be a good sta=
rting point for the architecture overview.


 


Please comment on whether or not this should become a working group do=
cument.


 


Regards,


 


Steve


 


_______________________________________________


Modern mailing list


Modern@ietf.org

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




 


_______________________________________________


Modern mailing list


Modern@ietf.org

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




 









_______________________________________________


Modern mailing list


Modern@ietf.org

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




 


 










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
















--_000_C73EA6BF72674878B468233B418AC846attcom_--


From nobody Mon Dec 14 11:16: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 C722F1B2DCA for ; Mon, 14 Dec 2015 11:16:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level: 
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-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 HjcrOriA0fav for ; Mon, 14 Dec 2015 11:16:10 -0800 (PST)
Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 189F81B2DC7 for ; Mon, 14 Dec 2015 11:16:09 -0800 (PST)
Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBEJG6tX008678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 14 Dec 2015 20:16:07 +0100
Received: from RHillNew (adsl-178-39-158-20.adslplus.ch [178.39.158.20]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBEJG5r8005598; Mon, 14 Dec 2015 20:16:06 +0100
From: "Richard Hill" 
To: "'Adam Roach'" , "'Steve Donovan'" , 
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com>
In-Reply-To: <566F1005.4050302@nostrum.com>
Date: Mon, 14 Dec 2015 20:16:05 +0100
Message-ID: <056701d136a3$e1c49120$a54db360$@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: AdE2oKt5NjCzyFahS/6CblHTDqFqoQAAnu1g
Content-Language: en-us
X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8
X-Antivirus-Code: 0x100000
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 14 Dec 2015 19:16:13 -0000

Please see below.

Thanks and best,
Richard

> -----Original Message-----
> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Adam Roach
> Sent: Monday, December 14, 2015 19:53
> To: Steve Donovan; modern@ietf.org
> Subject: Re: [Modern] Problem statement draft as working group document
> 
> On 12/10/15 12:40, Steve Donovan wrote:

SNIP

> 
> I think this document is a good starting point for outlining the basic
> shape of the problem and the use cases MODERN is intended to address.

Yes, but it seems to me to be placing the cart before the horse. The draft
is outlining technical solutions for things that aren't, as far as I know,
yet possible from a regulatory point of view.

That was to some extent also an issue with ENUM.

Wouldn't it be better to develop first the new desired regulatory framework,
and then to work out the technical solutions to implement number assignment,
etc., under the new regulatory framework?

> 
> I'll note that on-list objections so far seem to be attempting to re-
> litigate the formation of the working group rather than making progress
> towards its milestones. As has been long established (at least since
> the 2002 formation of XMPP), the decision to work on a problem in the
> IETF is based on the following criteria: "is it technically credible,
> are people willing to work on it, are people willing to use it?" 

Yes, and some of the objections do relate to credibility and to whether the
solution would be used in practice.

SNIP



From nobody Mon Dec 14 11:27:11 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0B21B2DDA for ; Mon, 14 Dec 2015 11:27:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IitZZZepC5kW for ; Mon, 14 Dec 2015 11:27:09 -0800 (PST)
Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 D1B911AD373 for ; Mon, 14 Dec 2015 11:27:08 -0800 (PST)
Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id tBEJORAf022420; Mon, 14 Dec 2015 14:27:04 -0500
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049458.ppops.net-00191d01. with ESMTP id 1yrfwxqqes-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);  Mon, 14 Dec 2015 14:27:03 -0500
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 tBEJR3RC025897; Mon, 14 Dec 2015 14:27:03 -0500
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 tBEJQn0L025656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Dec 2015 14:26:56 -0500
Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com [130.9.129.150]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Mon, 14 Dec 2015 19:26:34 GMT
Received: from MISOUT7MSGUSRDD.ITServices.sbc.com ([169.254.4.7]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0248.002; Mon, 14 Dec 2015 14:26:33 -0500
From: "PFAUTZ, PENN L" 
To: Adam Roach , Steve Donovan , "modern@ietf.org" 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHRNqHDiGM/I+6CPkS8NH280U5tDJ7K2s6Q
Date: Mon, 14 Dec 2015 19:26:33 +0000
Message-ID: <38726EDA2109264987B45E29E758C4D605925616@MISOUT7MSGUSRDD.ITServices.sbc.com>
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com>
In-Reply-To: <566F1005.4050302@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.59.176]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-12-14_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310007 definitions=main-1512140322
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 14 Dec 2015 19:27:10 -0000

QWxsLA0KSXQncyBzdGF0ZW1lbnRzIGxpa2UgDQoiIElkZWFsbHkgdGhlIHVzZXIgd291bGQgaGF2
ZSBmdWxsIGNvbnRyb2wgb2YgdGhlaXIgVE4gYW5kDQogICB3b3VsZCBkcml2ZSB0aGUgcG9ydGlu
ZyBwcm9jZXNzIG9uIHRoZWlyIG93biByYXRoZXIgdGhhbiByZWx5IG9uDQogICBjb21wbGV4IGFu
ZCB0aW1lIGNvbnN1bWluZyBiYWNrIG9mZmljZSBwcm9jZXNzZXMgYW1vbmcgbXVsdGlwbGUNCiAg
IHNlcnZpY2UgcHJvdmlkZXJzLiINCg0KdGhhdCBtYWtlIGEgcG9saWN5IHN0YXRlbWVudCB3aGlj
aCBjb25jZXJuIG1lLiANCg0KQXMgdG8gVG9tJ3MgcXVlc3Rpb24sIGl0IHdhcyB0aGUgc3RhdGVt
ZW50DQoiIE1vc3QgVE5zIHRvZGF5IGFyZSBhc3NpZ25lZCB0byBzcGVjaWZpYyBnZW9ncmFwaGll
cywgYXQgYm90aCBhbg0KICAgaW50ZXJuYXRpb25hbCBsZXZlbCBhbmQgd2l0aGluIG5hdGlvbmFs
IG51bWJlcmluZyBwbGFucy4gIFRoaXMgaGFzDQogICBzaGFwZWQgdGhlIHdheSB0aGF0IHNlcnZp
Y2UgcHJvdmlkZXJzIGludGVyY29ubmVjdCINCg0KSSB0aGluayBpdCB3YXMgdGhlIHJldmVyc2Ug
LSBudW1iZXJpbmcgZm9sbG93ZWQgaW50ZXJjb25uZWN0aW9uIC0gYW5kIHRoZSBtZWNoYW5pc21z
IEkgbmVlZCBmb3IgbnVtYmVyaW5nIHdpbGwgZGVwZW5kIG9uIHRoZSB0eXBlcyBvZiBpbnRlcmNv
bm5lY3Rpb24gSSBoYXZlIHRvIHN1cHBvcnQuDQoNClNvLCB5ZXMgSSBkbyBvYmplY3QgdG8gc3Bl
Y2lmaWNzIGluIHRoZSBkb2N1bWVudCBhcyBvcHBvc2VkIHRvIHRoZSBlbnRlcnByaXNlIGFzIGEg
d2hvbGUuICANCg0KUGVubiBQZmF1dHoNCkFUJlQgR2xvYmFsIENvbm5lY3Rpb24gTWFuYWdlbWVu
dA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBZGFtIFJvYWNoIFttYWls
dG86YWRhbUBub3N0cnVtLmNvbV0gDQpTZW50OiBNb25kYXksIERlY2VtYmVyIDE0LCAyMDE1IDE6
NTMgUE0NClRvOiBTdGV2ZSBEb25vdmFuOyBtb2Rlcm5AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb
TW9kZXJuXSBQcm9ibGVtIHN0YXRlbWVudCBkcmFmdCBhcyB3b3JraW5nIGdyb3VwIGRvY3VtZW50
DQoNCk9uIDEyLzEwLzE1IDEyOjQwLCBTdGV2ZSBEb25vdmFuIHdyb3RlOg0KPiBUaGVyZSBoYXMg
YmVlbiBubyByZXNwb25zZSB0byB0aGlzIHNvIEknbSBnb2luZyB0byBzdWdnZXN0IHdlIHB1dCBh
IA0KPiBkZWFkbGluZSBvbiBvcGluaW9ucy4NCj4NCj4gUGxlYXNlIGV4cHJlc3MgeW91ciBvcGlu
aW9uIG9uIG1ha2luZyANCj4gZHJhZnQtcGV0ZXJzb24tbW9kZXJuLXByb2JsZW1zLTAyIGEgd29y
a2luZyBncm91cCBkb2N1bWVudCBiZWZvcmUgDQo+IFRodXJzZGF5LCBEZWNlbWJlciAxN3RoLg0K
Pg0KPiBJdCBpcyBpbXBvcnRhbnQgdGhhdCBhbnlvbmUgd2hvIHN1cHBvcnRzIHRoZSBwcm9tb3Rp
b24gb2YgdGhlIGRvY3VtZW50IA0KPiBhbHNvIGV4cHJlc3MgdGhlaXIgb3Bpbmlvbi4NCg0KSSB0
aGluayB0aGlzIGRvY3VtZW50IGlzIGEgZ29vZCBzdGFydGluZyBwb2ludCBmb3Igb3V0bGluaW5n
IHRoZSBiYXNpYyANCnNoYXBlIG9mIHRoZSBwcm9ibGVtIGFuZCB0aGUgdXNlIGNhc2VzIE1PREVS
TiBpcyBpbnRlbmRlZCB0byBhZGRyZXNzLg0KDQpJJ2xsIG5vdGUgdGhhdCBvbi1saXN0IG9iamVj
dGlvbnMgc28gZmFyIHNlZW0gdG8gYmUgYXR0ZW1wdGluZyB0byANCnJlLWxpdGlnYXRlIHRoZSBm
b3JtYXRpb24gb2YgdGhlIHdvcmtpbmcgZ3JvdXAgcmF0aGVyIHRoYW4gbWFraW5nIA0KcHJvZ3Jl
c3MgdG93YXJkcyBpdHMgbWlsZXN0b25lcy4gQXMgaGFzIGJlZW4gbG9uZyBlc3RhYmxpc2hlZCAo
YXQgbGVhc3QgDQpzaW5jZSB0aGUgMjAwMiBmb3JtYXRpb24gb2YgWE1QUCksIHRoZSBkZWNpc2lv
biB0byB3b3JrIG9uIGEgcHJvYmxlbSBpbiANCnRoZSBJRVRGIGlzIGJhc2VkIG9uIHRoZSBmb2xs
b3dpbmcgY3JpdGVyaWE6ICJpcyBpdCB0ZWNobmljYWxseSANCmNyZWRpYmxlLCBhcmUgcGVvcGxl
IHdpbGxpbmcgdG8gd29yayBvbiBpdCwgYXJlIHBlb3BsZSB3aWxsaW5nIHRvIHVzZSANCml0PyIg
QW5kLCBpbiBwYXJ0aWN1bGFyOiAid2Ugc2hvdWxkIGJlIGRlY2lkaW5nIHRoaW5ncyBiYXNlZCBv
biB0aGUgDQpudW1iZXIgb2YgZm9sa3Mgd2hvIHdhbnQgdG8gZG8gdGhpbmdzLCBub3QgdGhlIG51
bWJlciBvcHBvc2VkLiINCg0KSW4gdGVybXMgb2YgY29uc2lkZXJpbmcgYWRvcHRpb24gb2YgdGhp
cyBzcGVjaWZpYyBkb2N1bWVudCwgSSB0aGluayB3ZSANCm5lZWQgdG8gYmUgY2FyZWZ1bCB0byBw
YXJzZSBvdXQgb2JqZWN0aW9ucyB0byBpdHMgY29udGVudHMgdmVyc3VzIA0Kb2JqZWN0aW9ucyB0
byBNT0RFUk4ncyB2ZXJ5IGV4aXN0ZW5jZS4gU28gZmFyLCBJIGhhdmUgc2VlbiBubyBvbi1saXN0
IA0Kb2JqZWN0aW9ucyB0aGF0IGZhbGwgaW4gdGhlIGZpcnN0IGNhdGVnb3J5Lg0KDQovYQ0KDQoN
Cg==


From nobody Mon Dec 14 11:36:30 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AE51B2E07 for ; Mon, 14 Dec 2015 11:36:29 -0800 (PST)
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 UxiBnNQ2bq6R for ; Mon, 14 Dec 2015 11:36:26 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90FE41B2DFC for ; Mon, 14 Dec 2015 11:36:26 -0800 (PST)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tBEJaKbe018258 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 14 Dec 2015 13:36:21 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
To: Richard Hill , "'Steve Donovan'" , modern@ietf.org
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com> <056701d136a3$e1c49120$a54db360$@ch>
From: Adam Roach 
Message-ID: <566F1A34.9020402@nostrum.com>
Date: Mon, 14 Dec 2015 13:36:20 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <056701d136a3$e1c49120$a54db360$@ch>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 14 Dec 2015 19:36:29 -0000

On 12/14/15 13:16, Richard Hill wrote:
> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Adam Roach
>
>> I think this document is a good starting point for outlining the basic
>> shape of the problem and the use cases MODERN is intended to address.
> Yes, but it seems to me to be placing the cart before the horse. The draft
> is outlining technical solutions for things that aren't, as far as I know,
> yet possible from a regulatory point of view.

Where you see a cart and a horse, I see a chicken and an egg. Someone 
has to go first. If taken in the opposite order, your objection could 
easily be reversed to read "the proposed regulations are outlining 
requirements for solutions that aren't, as far as I know, yet 
technically possible."

In any case, what we say on the topic in *this* forum is largely 
academic, since it's not the WG participants or even the chairs that 
decide to start and end WGs. If you'd like to debate the existence of 
MODERN -- which seems to be your implied intent -- that's a broader 
conversation that you need to take up with the ADs and the IESG. I'll 
note that the question of existence has already been asked and answered 
based on earlier discussions, so you'll need to show up with previously 
unmade arguments.

But that conversation doesn't have bearing on whether this document is a 
good match for the WG charter.

/a


From nobody Mon Dec 14 11:37:01 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E741B2DFA for ; Mon, 14 Dec 2015 11:36:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.324
X-Spam-Level: 
X-Spam-Status: No, score=0.324 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bE9Wi-AsERv for ; Mon, 14 Dec 2015 11:36:55 -0800 (PST)
Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) by ietfa.amsl.com (Postfix) with SMTP id 777371B2E08 for ; Mon, 14 Dec 2015 11:36:53 -0800 (PST)
Received: (qmail 26346 invoked by uid 0); 14 Dec 2015 19:36:53 -0000
Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy5.mail.unifiedlayer.com with SMTP; 14 Dec 2015 19:36:53 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with  id tXGq1r00S1MNPNq01XGtTH; Mon, 14 Dec 2015 12:16:53 -0700
X-Authority-Analysis: v=2.1 cv=IekUBwaa c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=P34Qx31D9VQA:10 a=wUQvQvOEmiQA:10 a=jqBRFv0mrdUA:10 a=PeFO9FbFhS32YxYntvkA:9 a=doUQZJtgAAAA:8 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=hGBaWAWWAAAA:8 a=izV7ms69AAAA:8 a=yakATiurAAAA:8 a=97Vmmk1_QAx5Ofd11dAA:9 a=vc40ephNWod_MUbS:21 a=KfQKc5ACOQBizYG8:21 a=QEXdDO2ut3YA:10 a=qM39cor4HRgA:10 a=K2lU_Ab98eoA:10 a=RpNjiQI2AAAA:8 a=M7Ay_mdbJ7_3lpKBMmwA:9 a=NTEA_F--SC2w5Oka:21 a=4X2ZglpXxsASxkEz:21 a=reRCVDHWTgG7YcIX:21 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us;  s=default;  h=Content-type:Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=AwtJ9ouBDFcceGmn3MyKusYOhLQHD+woduKamE1Jf1U=;  b=oBMmcvp11RBDR/LpLHv/0QyGyoqagpQWGMnhhtqVPSrKxSRr7vLPmr8vVkAGORgDvFl1cjQi/j2LBrUGE+pOBUoN9vq+cEckAtWXMMnrdjnsTmSoTmiblCfG28FI9F83;
Received: from [69.241.19.12] (port=37833 helo=[10.36.94.120]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1a8Yc6-0000C9-5m; Mon, 14 Dec 2015 12:16:50 -0700
User-Agent: Microsoft-MacOutlook/0.0.0.151105
Date: Mon, 14 Dec 2015 14:16:42 -0500
From: Richard Shockey 
To: "DOLLY, MARTIN C" , "McGarry, Tom" 
Message-ID: 
Thread-Topic: [Modern] Problem statement draft as working group document
References: <83ABC2CA-7EE2-4C3F-A759-C7A97EDDF1B2@att.com>  
In-Reply-To: 
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3532947410_1851426911"
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 69.241.19.12 authed with richard+shockey.us}
Archived-At: 
Cc: "modern@ietf.org" 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 14 Dec 2015 19:36:59 -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_3532947410_1851426911
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


Well I=E2=80=99m not a regulator nor do I play on on television, but I am a membe=
r of the North American Numbering Council [NANC] which is the Federal Adviso=
ry Committee to the US FCC on numbering issues.

https://www.fcc.gov/about-fcc/advisory-committees/north-american-numbering-=
council/general/nanc-membership

I=E2=80=99m not aware that issuing numbering resources directly to consumers or e=
nterprises is on the agenda.



From:  Modern  on behalf of "DOLLY, MARTIN C" 
Date:  Monday, December 14, 2015 at 1:59 PM
To:  "McGarry, Tom" 
Cc:  "modern@ietf.org" 
Subject:  Re: [Modern] Problem statement draft as working group document

It would be nice to hear a regulator point of view.=20
The FCC assigns numbers to entities (eg. SP) that they can regulate and if =
there is misbehavior punish. This point has been made over and over again

Martin C Dolly=20
Lead Member of Technical Staff
Core & Government/Regulatory Standards=20
AT&T
Cell: 609-903-3360
Email: md3135@att.com

On Dec 14, 2015, at 1:49 PM, McGarry, Tom  wrote:

Ok, I'm aware that some people do not like the concept of number assignment=
 to users. =20

But there is interconnection, does that mean this is relevant? =20

From: , Martin Dolly 
Date: Monday, December 14, 2015 1:44 PM
To: Tom Mcgarry 
Cc: "PFAUTZ, PENN L" , Modern List 
Subject: Re: [Modern] Problem statement draft as working group document

Number assignment to users has been an is from day 1.=20
If there was no Interconnection, none of this would be relevant=20

Martin C Dolly=20
Lead Member of Technical Staff
Core & Government/Regulatory Standards=20
AT&T
Cell: 609-903-3360
Email: md3135@att.com

On Dec 14, 2015, at 1:31 PM, McGarry, Tom  wrote:

Thanks Penn. =20

I don't understand your point about numbering vs interconnection.  Is there=
 something in the document you can point to?

Also can you point me to the statements about user and SP roles?  =20

From: , PENN L 
Date: Monday, December 14, 2015 12:57 PM
To: Pierce Gorman , Steve Donovan , Modern List 
Subject: Re: [Modern] Problem statement draft as working group document

I find that I need to object as well. It is not numbering that drives inter=
connection so much as interconnection drives numbering. As the evolution of =
interconnection even as the PSTN migrates to an IP backbone is by no means s=
ettled I=E2=80=99m concerned that we are getting the cart before the horse. I also=
 object to the conclusory statements about user and service provider roles; =
I think the picture is more complicated.

I remain sympathetic to the goal of modernizing number administration and r=
outing but the document is problematic for me.

=20

Penn Pfautz

AT&T Global Connection Management

=20

=20

From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com]=20
Sent: Monday, December 14, 2015 10:52 AM
To: Steve Donovan; modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

=20

If an actual reason is not required I would like to add my vote of dissensi=
on on principal without having to actually read the =E2=80=9Cdraft-peterson-modern=
-problems-02=E2=80=9D.  You might recall I argued with the language in the charter=
 but I and others were over-ruled by the Area Directors.

=20

Pierce Gorman

=20

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: December 14, 2015 8:45 AM
To: modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

=20

Eric,

Could you elaborate on why you think the document should not become a worki=
ng group item.

Thanks,

Steve

On 12/10/15 7:05 PM, Eric Burger wrote:
Nah. :-)
=20
On Dec 10, 2015, at 1:40 PM, Steve Donovan  wrote=
:
=20
There has been no response to this so I'm going to suggest we put a deadlin=
e on opinions.
=20
Please express your opinion on making draft-peterson-modern-problems-02 a w=
orking group document before Thursday, December 17th.
=20
It is important that anyone who supports the promotion of the document also=
 express their opinion.
=20
Thanks,
=20
Steve
=20
On 11/13/15 3:53 PM, Steve Donovan wrote:
All,
=20
During the IETF94 MODERN WG meeting there was consensus that draft-peterson=
-modern-problems-02 be accepted as a working group document.  This would be =
to address the architecture Architecture Overview milestone.
=20
It was recognized that it is not in final form but would be a good starting=
 point for the architecture overview.
=20
Please comment on whether or not this should become a working group documen=
t.
=20
Regards,
=20
Steve
=20
_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern
=20
_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern
=20


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

=20


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

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

--B_3532947410_1851426911
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable



Well I’m not a regulator nor do I play on on television, but I=
 am a member of the North American Numbering Council [NANC] which is the Fed=
eral Advisory Committee to the US FCC on numbering issues.


I’m not aware that issuing numbering =
resources directly to consumers or enterprises is on the agenda.
<=
br>


From:  Modern <modern-bounces@ietf=
.org> on behalf of "DOLLY, MARTIN C" <md3135@att.com>
Date:  M=
onday, December 14, 2015 at 1:59 PM
To:  "McGarry, Tom" <Tom.McGarr=
y@neustar.biz>
Cc:  "modern@ietf.org" <modern@ietf.org>
Subject: <=
/span> Re: [Modern] Problem statement draft as working group document

It would be nice to hear a regulat=
or point of view. 
The FCC assigns nu=
mbers to entities (eg. SP) that they can regulate and if there is misbehavio=
r punish. This point has been made over and over again


Martin C Dolly

Lead Member of Technical Staff
Core & Government/Regulat=
ory Standards 
AT&T
Cell: 609-903-3360
Email: md3135@att.com
=


On Dec 14, 2015, at 1:49 PM, McGarry, Tom <Tom.McGarry@neustar.biz> wrote:

Ok, I'm aware that some people do not like the concept=
 of number assignment to users.  

But there is=
 interconnection, does that mean this is relevant?  

<=
span style=3D"font-weight:bold">From: <DOLLY>, Martin Dolly <<=
a href=3D"mailto:md3135@att.com">md3135@att.com>
Date: Monday, December 14, 2015 1:44 PM
To: Tom Mcgarry <tom.mcgarry@neustar.biz>
C=
c: "PFAUTZ, PENN L" <pp3129@att.co=
m>, Modern List <modern@ietf.org<=
/a>>
Subject: Re: [Modern] Probl=
em statement draft as working group document

=


On Dec 14, 2015, at 1:31 PM, McGarry, Tom <Tom.McGarry@neustar.biz> wrote:

Thanks Penn.  

I don't u=
nderstand your point about numbering vs interconnection.  Is there some=
thing in the document you can point to?

Also can yo=
u point me to the statements about user and SP roles?   

From: <PFAUTZ>, PENN L &=
lt;pp3129@att.com>
Date: Monday, December 14, 2015 12:57 PM
To: Pierce Gorman <Pierce.Gorman@sprint.com>, Steve Donovan <srdonovan@usdonovans.com>, Modern =
List <modern@ietf.org>
Subject: Re: [Modern] Problem statement draft=
 as working group document

I find that I need to object as well. It is not numbering that drives =
interconnection so much as interconnection drives numbering. As the evolutio=
n
 of interconnection even as the PSTN migrates to an IP backbone is by no me=
ans settled I’m concerned that we are getting the cart before the hors=
e. I also object to the conclusory statements about user and service provide=
r roles; I think the picture is more
 complicated.
I re=
main sympathetic to the goal of modernizing number administration and routin=
g but the document is problematic for me.
 
Penn Pfautz
AT&T Global Connection Management
 
 
From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com]

Sent: Monday, December 14, 2015 10:52 AM
To: Steve Don=
ovan; modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document<=
/span>
 
If an actual reason is not required I would like to add =
my vote of dissension on principal without having to actually read the ̶=
0;draft-peterson-modern-problems-02”. 
 You might recall I argued with the language in the charter but I and other=
s were over-ruled by the Area Directors.
 
&n=
bsp;
From: Modern [mailto:moder=
n-bounces@ietf.org]
On Behalf Of Steve Donovan
Sent: December 14, 2015 8:45 AM=

To: modern@ietf.org
Su=
bject: Re: [Modern] Problem statement draft as working group document
 
Eric,


Could you elaborate on why you think the document should not become a worki=
ng group item.
Thanks,


Steve
On 12/10/15 7:05 PM, Eric Bur=
ger wrote:
Nah. :-)
 
On Dec 10, 2015, at =
1:40 PM, Steve Donovan <srdonov=
an@usdonovans.com> wrote:
 
There has been no response to this so I'm going to suggest we put a de=
adline on opinions.
 
Please =
express your opinion on making draft-peterson-modern-problems-02 a working g=
roup document before Thursday, December 17th.
&nbs=
p;
It is important that anyone who supports the promotion of=
 the document also express their opinion.
 
Thanks,
 
Stev=
e
 
On 11/13/15 3:53 PM, Stev=
e Donovan wrote:
All,
 
Dur=
ing the IETF94 MODERN WG meeting there was consensus that draft-peterson-mod=
ern-problems-02 be accepted as a working group document.  This would be=
 to address the architecture Architecture Overview milestone.
 
It was recognized that it is not in final=
 form but would be a good starting point for the architecture overview.=

 
Please comment on whether or no=
t this should become a working group document.
&nb=
sp;
Regards,
 
Steve
 
___________________=
____________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/mailman/listinfo/modern
 
_________________________________=
______________
Modern mailing list
Modern@ietf.org
<=
a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma=
ilman_listinfo_modern&d=3DCwMFAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32=
iB7HufveeIDcLextZ1ooNcfp01IYIaVqsORjI&m=3DVoOj5l8qS_slWFPQFyFGHcwCy5IpNAua=
33eYtYDOYgw&s=3DL7HtO_ci3KGlrlZPQbTUPkKpDn5fARTZE7PYD-WeWPM&e=3D">https:=
//www.ietf.org/mailman/listinfo/modern
 

_______________________________________________
Modern mailing list
Modern@ietf.org
https://www.ietf.org/ma=
ilman/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 t=
he intended recipient, please contact the sender and delete all copies of th=
e message.
_______________________________________________
Modern m=
ailing list
Modern@ietf.org=

https://www.ietf.org/mailman/listinfo/modern
<=
/div>

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


--B_3532947410_1851426911--



From nobody Mon Dec 14 11:42:19 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E6D1B2E17 for ; Mon, 14 Dec 2015 11:42:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.088
X-Spam-Level: 
X-Spam-Status: No, score=0.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCXecQhhz2KB for ; Mon, 14 Dec 2015 11:42:05 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0797.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:797]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 757491B2E2C for ; Mon, 14 Dec 2015 11:41:47 -0800 (PST)
Received: from BN1AFFO11FD054.protection.gbl (10.58.52.30) by BN1AFFO11HUB036.protection.gbl (10.58.52.147) with Microsoft SMTP Server (TLS) id 15.1.346.13; Mon, 14 Dec 2015 19:41:30 +0000
Authentication-Results: spf=pass (sender IP is 144.230.32.82) smtp.mailfrom=sprint.com; att.com; dkim=none (message not signed) header.d=none;att.com; dmarc=bestguesspass action=none header.from=sprint.com;
Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.32.82 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.82; helo=preapdm3.corp.sprint.com;
Received: from preapdm3.corp.sprint.com (144.230.32.82) by BN1AFFO11FD054.mail.protection.outlook.com (10.58.53.69) with Microsoft SMTP Server (TLS) id 15.1.346.13 via Frontend Transport; Mon, 14 Dec 2015 19:41:30 +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 tBEJJmVM016115;  Mon, 14 Dec 2015 14:41:30 -0500
Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by preapdm3.corp.sprint.com with ESMTP id 1yreq78p80-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 14 Dec 2015 14:41:30 -0500
Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M07.ad.sprint.com (2002:90e2:801a::90e2:801a) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 14 Dec 2015 14:41:29 -0500
Received: from PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed]) by PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed%24]) with mapi id 15.00.1076.000; Mon, 14 Dec 2015 13:41:28 -0600
From: "Gorman, Pierce A [CTO]" 
To: "DOLLY, MARTIN C" , "McGarry, Tom" 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHRNn38KCigIa6jakmAIZNM6lCGV57Kn4nQgACJ6wCAAAlPgIAAA8aA//+cy8A=
Date: Mon, 14 Dec 2015 19:41:28 +0000
Message-ID: <76318e83d917441c8843bed9f11e901b@PLSWE13M08.ad.sprint.com>
References: <38726EDA2109264987B45E29E758C4D60592552D@MISOUT7MSGUSRDD.ITServices.sbc.com>,  <83ABC2CA-7EE2-4C3F-A759-C7A97EDDF1B2@att.com>
In-Reply-To: <83ABC2CA-7EE2-4C3F-A759-C7A97EDDF1B2@att.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.214.116.44]
Content-Type: multipart/alternative; boundary="_000_76318e83d917441c8843bed9f11e901bPLSWE13M08adsprintcom_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD054; 1:1jZKf0t0zaUAKcpnCLvzsWgpM045BBqrdrKDxh58yK98mzfRBqnnsukdGAgMLQ0LVkB9qCr6+g04FKY56umZbnZbzj2CVwcqtmS1jCSM+syZkZOazc4thGpQfB5YYySG68b9glcmJCH+nBE4F9PHgmgnItdHZKV4ywAA/tKlJnsSkL5a4B4fmVKKj1jkRkf/047MpXp+CY0RK2kW7FVCBkPvunwbOVbNa4rxwWO5ZDJLeNZGk8nHqiCa4c0y8s8wnIe3rLuWYjwTKNSwo9rw/HpKAIAa1n90she58ab3yeN4+OkDZ2xYqg98EDAzaQUSqlnRw0Tc1AzqYKMdJAO0niiHyLvClFCM20nvkMmQs0I=
X-Forefront-Antispam-Report: CIP:144.230.32.82; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(438002)(164054003)(252514010)(377454003)(199003)(189002)(38284003)(24454002)(479174004)(87936001)(108616004)(15975445007)(19625215002)(24736003)(3846002)(5003600100002)(6116002)(19300405004)(4546004)(1220700001)(19617315012)(102836003)(11100500001)(1096002)(16236675004)(790700001)(19580405001)(92566002)(5008740100001)(512954002)(33646002)(97736004)(586003)(30436002)(86362001)(81156007)(5004730100002)(19580395003)(76176999)(300700001)(54356999)(2900100001)(2950100001)(106466001)(5001770100001)(84326002)(325944007)(260700001)(106116001)(50986999)(189998001)(5250100002)(5001960100002)(6806005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB036; H:preapdm3.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB036; 2:6LGng2MMGnwI3lyJxzaUkEpJU85EFj3LUGY6d8V7yYWR1AlvE4mmR/HinR8Dxg36t7W+T2pH4R65nTgQvh9iErgZ2qN8M2SVloh7VOOBk9BhsluA8MTGGUQ73AkUVRaeIkAXt9DtffwPzBosqjgbNA==; 3:k9YLjpbkbrHk+XLwnpJffUz69mO/xnirpbSrUUk+KRob61CAZC1QpySlWwPVPmmLHQPnyA8sUT9ojrClPQ6uavWLw+EhdTnoymVaj4J1jvfkKd+HyyLDh7M7H6JBFmXYGSzJtHtX6LtbQEaLGSDht3o6g77ezZxSFl2BiDyJgbVZSKwlGW8VN6iCBX8Bu7CYboinkaazXr+gA9/Op7/QJmqwJzjzyu5jr8GxMZ1bkJec8TdfKu7CctPjcu1sBOkddAg1B8+bYqS2UywTiZ1JCQ==; 25:Rb0+5X+i09MGBZFoHeMcWB1xZsJm8OUnRAFFyAxE6u7Uvhp+r4l5HZ8SkhyJrJO7H19o1ITvimP90nVEa/UCwN0vBXWq3Y/+OGWZBIgRNxEs2fce2MxDD8aCs7VjDRAZsOLq+ElYliXjX02PrvrVoAKDbsZt9l7sKRuBJ2L2HMcr0o5XqfKUdnlEerzu0lAwyd7VdwYx8hQWWtOivADvtfU0Rq4XWjCgQeGUP1y12fncgCPArHaj3oIJzCe7RwRaOm6YG8CV7EuFtjE66WMk2A==
X-Exchange-Antispam-Report-Test: UriScan:; BCL:0; PCL:0; RULEID:(8251501002);  SRVR:BN1AFFO11HUB036; UriScan:(18430343700868)(97927398514766); 
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB036; 20:b+n2JYeWyUkhUFCY3jkdA9E2iGGz16z2fc2OPZf/vR6DSQGfKPziFEdbyT0DTCse5gmlfYpePDnWME6W+quxmLbsgnWuUcghW8c4x/Dj/G3dBxgjd3EnPd7Um6jRtixC5zaOUtsJ5/iXIreW7oI+8VdvkggWTCb+b2xJ/6x16klYCx7+NoozCls+Ee86DBHH94K1w73eZPjbOkViII7EGoFh9BQMYXXB+CbS+XmrcGjEm33OkmUY4iTIPiUJKIaM; 4:TOdweUUMacULtfr5Hly7ziQAFtabKT9O8ufK5paVQPoi3t7A8BLrv+F/Q8xhPdFYBsiGYy2euixhwWdH1GC0tyIRXzwGWsuAM3cUtoLpswRnQWjVmu0RpBUK/wRpprK7hwkbPTmNRdJIsxOg26s9Fa4L89TUlnJkYy9SVWgycG5RZUS3xkuyuk7Ltc8Y+LH7fwsoLcbiLxjH0/PfQPJcYn5RF9bsQHT+07EMz4F4vpT5JEmev36zCk3SUVEz70W2aOrH8ZoyUReksutslZB/LeDWv/bsVhePMuMXtygpXGWd85C4mk/f3tj+FKuUXOhuJV156BU5iKrAHO7cIVPWKEt9t4TIdfFUziKFBQQ/TI/kWekvoMiJ83Yr727KtHxw10q2sQ7fB9w8peH4qrpCjI0XnjjSHcBeY9Rp+/KFGY/DaVVmwLssXE8uwNiNKEx01f19gRk8uSO2QLJT8azLRg==
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN1AFFO11HUB036; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB036; 
X-Forefront-PRVS: 0790FB1F33
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1AFFO11HUB036; 23:/ohaWK+Ia4pZqQoMgDLIVv4r7V4T9RoD1tbCTRv?= =?us-ascii?Q?PN9mhCWtf6r+t+kmWYdddYhq4pR+fvLo+HvxdpETQxfAmEoRGWyu3zuVddEQ?= =?us-ascii?Q?xCgjBfUwacIsA9Tfw98k12P392LTEUm8i5IVUg8OR2SzFjyBihxNPMavRBbS?= =?us-ascii?Q?WsNOGolSbjJt9hlC0lJsBK8lJVE7CkSoFxDYNyer49lFKPzS1T5SpgV74nW4?= =?us-ascii?Q?2krDrMx25igl5h0B7RvH1XN6F6TWKdY8fczALkLepj3AXKKVFGtp4LXxqUh9?= =?us-ascii?Q?VVJALLTzlsZFp+Mxo8UsOpvS0eja5l/H+UcbUTm2/bokFTPXEvwaxFEq/wqn?= =?us-ascii?Q?amwlGG0oKtbZrASPfjmXoV6cerPbb2NPKM7+BowX61x1PTqvZnGV1hqTGEb5?= =?us-ascii?Q?l/uTC8yLcSEGVfVtHqGXV39kO9/0rQXpQWYjntD6bPNj6SLii3SNrUDVrHHf?= =?us-ascii?Q?WYXL+Ut+GfWDNNe5MhQpUQP1J3C8Xe8fIdtPxpcfS6PsB8S5h8Jim6M3YPKh?= =?us-ascii?Q?8h72O8qYOsybzyPI0qA81PhEP/F7S4UyG6Xr2eIy4HcFzPsKXMWFC8yu3cpo?= =?us-ascii?Q?uLLJfiGxUbEUyCU0MTBAP/o3udCHKWIkzE5vmSEfCiOyU3z65LRBvnQx32Yu?= =?us-ascii?Q?rhQ4ZIDhVXPU+OlA2InSu53OwRHH/QQqJ2wscfFWoOrwpuN0/b1TLGyCZoXq?= =?us-ascii?Q?bwlEkJpTlL1r93BNpo4k4mcDneoVGYdR8SBaCiZmsTlWnBAazDjWqJ2Kj0Hm?= =?us-ascii?Q?XqbBMpfSnnfAYFHiFpbF9MZgYdqMT6Ws0H79TD34VzFIld1Pv6XHvdK6tX2I?= =?us-ascii?Q?FaCZxtoo4XJPtLqpUDPx/CyH9zhgsAESiQQzLKLbEDf69g4JMxkp5FpFw/SH?= =?us-ascii?Q?sMCPH5ULWCZTihdxsqiaLAmkaucg1mMMNsH1waDZwGavzXBE9SbpMqjlJtYr?= =?us-ascii?Q?4i3NbMXAqdiIFFbU9qYnXUhwzt13rsmgMZJGhx5GHuAsOwdi9UlOzjchR7US?= =?us-ascii?Q?urDxeDj/ICycPHmWX2F4ts3aNd88RD+Hzg2mOIPmwT5O5HnUAnIUefYgdcej?= =?us-ascii?Q?opinGI/45KPCFVGtJoYLaU452/szt1SLexT4Zq+GvlEebholtcvaEQb5oArq?= =?us-ascii?Q?6zLAiM2/lS5UZE1+AHjmqlFn6XlWLDp1LwcqCweN7pFGWS7NkoZ2W708zHby?= =?us-ascii?Q?d6XdrctRnKtMFoo05Df+f5SoQeBiLagXuS8kSiomzPMFtF85t3mkQJsLA+rE?= =?us-ascii?Q?Y9zR6K7N1e5Qf2mO6+HGmNeDflF+sc9yy+IBvkbRgfXWpvX37/eNOMEOOAsV?= =?us-ascii?Q?YIgL9Lg5If97iLtE2LfRjaj5ZSdZxD4nR72zyW23OmOXo3i/xd6L38rR46vg?= =?us-ascii?Q?LT/GRS448MXwXVi0C0AXDBsWabVywfIYJMr/YdcVdrIJc9T8AI/7oYZ+sGG6?= =?us-ascii?Q?e5Ws+BJFyZ67+93Jl5hSAo7gOv51YQr/UrJqyCYMRN4mQJ/ya5Tz5?=
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB036; 5:f7lvRnBKcHRm7tSzN59DDxZLMsA8Mmq548f4d8EOPfYjz+bo5SYcuk15rQ8LNq+cd+6Pth8L80PRZFvnS5b0fsYQp8DbuFm3L4CCHL9AsWbGbWyYmmZqsMmRXOOR0ZxxjjGYXXdKOcRwhUSp05bcuQ==; 24:BeMSMZyGoFvfoBCnNgbaO4glMj9ZCAckO8uHbZrm9uXdApNACNCZs0+4PINbRHOhj09hmR1Sbuc2xOniALSSsNA/tj7svspTsg0XX2KtxMo=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: sprint.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Dec 2015 19:41:30.7431 (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: BN1AFFO11HUB036
Archived-At: 
Cc: "modern@ietf.org" , "PFAUTZ, PENN L" 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 14 Dec 2015 19:42:15 -0000

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

Not sure where I'm allowed to start listing objections and which would be c=
onsidered substantive and which would be considered irrelevant nits, but I'=
ll offer a few now and add as time and interest permits.


In Section 1 Problem Statement I object to the assertion, "The original ENU=
M concept of a single root, e164.arpa, proved to be politically challenging=
, and less centralized models have thus flourished."  The fundamental probl=
em was not that ENUM was "politically challenging".  ENUM was also practica=
lly challenging, on multiple levels.



First and foremost, ENUM in e164.arpa had no concept that route selection c=
ould not simply be made based on where a terminating number was being serve=
d from.  Route selection had to almost always also be based on the type of =
number that was being called and where a call was originating from.  The or=
iginal DNS-only ENUM approach failed to accomodate those requirements.



The less-centralized models didn't flourish because of a lack of political =
challenges.  They flourished because proprietary non-DNS database implement=
ations which used the DNS resource record query/response protocols overcame=
 fundamental limitations of a strictly e164.arpa implementation.



Another assertion I find objectionable is, "Telephone numbering, however, h=
as long been transitioning away from a provider-centric model towards a use=
r-centric model."  The example of number portability overlooks the fact tha=
t the ported number is assigned a pointer back into a provider-centric mode=
l of routing information domestically known as the LERG.



It goes on to say, "Thanks to the increasing sophistication of consumer mob=
ile devices, users now associate TNs with many applications other than tele=
phony." So the assertion is made that (mobile) users (of smart phones) can =
easily associate services with their telephone numbers.  No argument.  How =
is this a problem?



Next the argument is made that, "Ideally the user would have full control o=
f their TN and would drive the porting process on their own rather than rel=
y on complex and time consuming back office processes among multiple servic=
e providers."  This is interesting.  Who has control over a TN being ported=
 if not the end user?



Is the thought that the user no longer would require the services of a serv=
ice provider?



Or is it that service providers will constantly troll the MODERN database l=
ooking for users who've selected them to be their service provider?



How would the losing SP (if there is one), learn they've been de-selected?



How does the commercial relationship between the new SP and the user get es=
tablished?  Careful, it might look like an awful lot like a "complex and ti=
me consuming back office" process.



Will this new method of self-registration and de-registration, and commerci=
al relationship establishment somehow gain material benefit over the existi=
ng "complex and time consuming back office processes among multiple service=
 providers"?



What was the problem or problems that were solved?  Do users really care ab=
out the complexity of a change between service provider back-office systems=
? How could they?  They have no visibility to it other than the caveat that=
 it might take a few hours before the port was complete.  What is the avera=
ge time for port completion?  Is there really a problem here to solve?  Wha=
t will that port time look like after the conversion from the current NP pr=
ovider (domestically) and the new NP provider?  Is porting a problem intern=
ationally?  Is MODERN going to fix international  porting problems?



And, I can't let it go unsaid that the claim end users are harmed by "compl=
ex and time consuming back office processes among multiple service provider=
s" ignores the fact that the service providers are forced to rely on system=
s developed and managed through a regulated back-office provider which fran=
kly seems somewhat disingenuous given who is advancing the arguments.

Pierce Gorman
From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C
Sent: December 14, 2015 12:45 PM
To: McGarry, Tom 
Cc: modern@ietf.org; PFAUTZ, PENN L 
Subject: Re: [Modern] Problem statement draft as working group document

Number assignment to users has been an is from day 1.
If there was no Interconnection, none of this would be relevant

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: 609-903-3360
Email: md3135@att.com

On Dec 14, 2015, at 1:31 PM, McGarry, Tom > wrote:
Thanks Penn.

I don't understand your point about numbering vs interconnection.  Is there=
 something in the document you can point to?

Also can you point me to the statements about user and SP roles?

From: , PENN L >
Date: Monday, December 14, 2015 12:57 PM
To: Pierce Gorman >, Steve Donovan >, Modern List >
Subject: Re: [Modern] Problem statement draft as working group document

I find that I need to object as well. It is not numbering that drives inter=
connection so much as interconnection drives numbering. As the evolution of=
 interconnection even as the PSTN migrates to an IP backbone is by no means=
 settled I'm concerned that we are getting the cart before the horse. I als=
o object to the conclusory statements about user and service provider roles=
; I think the picture is more complicated.
I remain sympathetic to the goal of modernizing number administration and r=
outing but the document is problematic for me.

Penn Pfautz
AT&T Global Connection Management


From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com]
Sent: Monday, December 14, 2015 10:52 AM
To: Steve Donovan; modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

If an actual reason is not required I would like to add my vote of dissensi=
on on principal without having to actually read the "draft-peterson-modern-=
problems-02".  You might recall I argued with the language in the charter b=
ut I and others were over-ruled by the Area Directors.

Pierce Gorman

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: December 14, 2015 8:45 AM
To: modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

Eric,

Could you elaborate on why you think the document should not become a worki=
ng group item.
Thanks,

Steve
On 12/10/15 7:05 PM, Eric Burger wrote:

Nah. :-)



On Dec 10, 2015, at 1:40 PM, Steve Donovan  wrote:



There has been no response to this so I'm going to suggest we put a deadlin=
e on opinions.



Please express your opinion on making draft-peterson-modern-problems-02 a w=
orking group document before Thursday, December 17th.



It is important that anyone who supports the promotion of the document also=
 express their opinion.



Thanks,



Steve



On 11/13/15 3:53 PM, Steve Donovan wrote:

All,



During the IETF94 MODERN WG meeting there was consensus that draft-peterson=
-modern-problems-02 be accepted as a working group document.  This would be=
 to address the architecture Architecture Overview milestone.



It was recognized that it is not in final form but would be a good starting=
 point for the architecture overview.



Please comment on whether or not this should become a working group documen=
t.



Regards,



Steve



_______________________________________________

Modern mailing list

Modern@ietf.org

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



_______________________________________________

Modern mailing list

Modern@ietf.org

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






_______________________________________________

Modern mailing list

Modern@ietf.org

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


________________________________

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

________________________________

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

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











Not sure where I’m allowed to sta=
rt listing objections and which would be considered substantive and which w=
ould be considered irrelevant nits, but I’ll offer a
 few now and add as time and interest permits.


 


In Section 1 Problem Statement I object to the assertion,=
 “The original ENUM concept o=
f a single root, e164.arpa, proved to be politically challenging, and less =
centralized models have thus flourished.”  T=
he fundamental problem was not that ENUM was “politically challenging“.  =
ENUM was also practically challenging, on multiple levels.


 


First and foremost, ENUM in e164.arpa had no concept that=
 route selection could not simply be made based on where a terminating numb=
er was being served from.  Route selection had to almost always also b=
e based on the type of number that was being called and where a call was or=
iginating from.  The original DNS-only ENUM approach failed to accomod=
ate those requirements.


 


The less-centralized models didn’t flourish because=
 of a lack of political challenges.  They flourished because proprieta=
ry non-DNS database implementations which used the DNS resource record quer=
y/response protocols overcame fundamental limitations of a strictly e164.ar=
pa implementation.


 


Another assertion I find objectionable is, “=
Telephone numbering, however, has long bee=
n transitioning away from a provider-centric model towards a user-centric m=
odel.”  The example of number portability ov=
erlooks the fact that the ported number is assigned a pointer back into a p=
rovider-centric model of routing information domestically known as the LERG=
.


 


It goes on to say, “Thanks to the increasing sophistication of consumer mobile devices=
, users now associate TNs with many applications other than telephony.̶=
1; So the assertion is made that (mobile) users (of sma=
rt phones) can easily associate services with their telephone numbers. =
; No argument.  How is this a problem?


 


Next the argument is made that, “Ideally the user would have full control of their TN =
and would drive the porting process on their own rather than rely on comple=
x and time consuming back office processes among multiple service providers=
.“  This is interesting.  Who has contr=
ol over a TN being ported if not the end user?


 


Is the thought that the user no longer would require the =
services of a service provider?


 


Or is it that service providers will constantly troll the=
 MODERN database looking for users who’ve selected them to be their s=
ervice provider?


 


How would the losing SP (if there is one), learn theyR=
17;ve been de-selected?


 


How does the commercial relationship between the new SP a=
nd the user get established?  Careful, it might look like an awful lot=
 like a “complex and time con=
suming back office” process.

 


Will this new method of self-registration and de-registra=
tion, and commercial relationship establishment somehow gain material benef=
it over the existing “complex=
 and time consuming back office processes among multiple service providers<=
/span>“?


 


What was the problem or problems that were solved?  =
Do users really care about the complexity of a change between service provi=
der back-office systems? How could they?  They have no visibility to i=
t other than the caveat that it might take a few hours before the port was =
complete.  What is the average time for port completion?  Is ther=
e really a problem here to solve?  What will that port time look like =
after the conversion from the current NP provider (domestically) and the ne=
w NP provider?  Is porting a problem internationally?  Is MODERN =
going to fix international  porting problems?


 


And, I can’t let it go unsaid that the claim end us=
ers are harmed by “complex an=
d time consuming back office processes among multiple service providers” ignores the fact that the service providers are for=
ced to rely on systems developed and managed through a regulated back-offic=
e provider which frankly seems somewhat disingenuous given who is advancing=
 the arguments.


 


Pierce Gorman






From: Modern [mailto:modern-bounces@ietf.org]
On Behalf Of DOLLY, MARTIN C

Sent: December 14, 2015 12:45 PM

To: McGarry, Tom <Tom.McGarry@neustar.biz>

Cc: modern@ietf.org; PFAUTZ, PENN L <pp3129@att.com>

Subject: Re: [Modern] Problem statement draft as working group docum=
ent






 




Number assignment to users has been an is from day 1=
. 






If there was no Interconnection, none of this would =
be relevant 



Martin C Dolly 




Lead Member of Technical Staff






Core & Government/Regulatory Standards 






AT&T






Cell: 609-903-3360











On Dec 14, 2015, at 1:31 PM, McGarry, Tom <Tom.McGarry@neustar.biz> wrote:










Thanks Penn.  






 






I don't understand your point about numbering vs int=
erconnection.  Is there something in the document you can point to?






 






Also can you point me to the statements about user a=
nd SP roles?   






 






From:
<PFAUTZ>, PENN L <pp=
3129@att.com>

Date: Monday, December 14, 2015 12:57 PM

To: Pierce Gorman <Pi=
erce.Gorman@sprint.com>, Steve Donovan <srdonovan@usdonovans.com>, Modern List <modern@ietf.org>

Subject: Re: [Modern] Problem statement draft as working group docum=
ent






 








I find that I need to object as well.=
 It is not numbering that drives interconnection so much as interconnection=
 drives numbering. As the evolution of interconnection
 even as the PSTN migrates to an IP backbone is by no means settled I’=
;m concerned that we are getting the cart before the horse. I also object t=
o the conclusory statements about user and service provider roles; I think =
the picture is more complicated.


I remain sympathetic to the goal of m=
odernizing number administration and routing but the document is problemati=
c for me.


 


Penn Pfautz


AT&T Global Connection Management=



 


 






From: Gorman, Pierce A [CTO] [mai=
lto:Pierce.Gorman@sprint.com]


Sent: Monday, December 14, 2015 10:52 AM

To: Steve Donovan; modern@ietf.or=
g

Subject: Re: [Modern] Problem statement draft as working group docum=
ent






 


If an actual reason is not required I w=
ould like to add my vote of dissension on principal without having to actua=
lly read the “draft-peterson-modern-problems-02&#=
8221;. 
 You might recall I argued with the language in the charter but I and other=
s were over-ruled by the Area Directors.


 


Pierce Gorman


 






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

Sent: December 14, 2015 8:45 AM

To: modern@ietf.org

Subject: Re: [Modern] Problem statement draft as working group docum=
ent






 


Eric,



Could you elaborate on why you think the document should not become a worki=
ng group item.


Thanks,



Steve




On 12/10/15 7:05 PM, Eric Burger wrote:





Nah. :-)


 




On Dec 10, 2015, at 1:40 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 


There has been no response to this so I'm going to suggest we put a de=
adline on opinions.


 


Please express your opinion on making draft-peterson-modern-problems-0=
2 a working group document before Thursday, December 17th.


 


It is important that anyone who supports the promotion of the document=
 also express their opinion.


 


Thanks,


 


Steve


 


On 11/13/15 3:53 PM, Steve Donovan wrote:




All,


 


During the IETF94 MODERN WG meeting there was consensus that draft-pet=
erson-modern-problems-02 be accepted as a working group document.  Thi=
s would be to address the architecture Architecture Overview milestone.


 


It was recognized that it is not in final form but would be a good sta=
rting point for the architecture overview.


 


Please comment on whether or not this should become a working group do=
cument.


 


Regards,


 


Steve


 


_______________________________________________


Modern mailing list


Modern@ietf.org

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




 


_______________________________________________


Modern mailing list


Modern@ietf.org

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




 











_______________________________________________


Modern mailing list


Modern@ietf.org

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




 


 <=
/o:p>










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














___________________=
____________________________

Modern mailing list

Modern@ietf.org

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













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





--_000_76318e83d917441c8843bed9f11e901bPLSWE13M08adsprintcom_--


From nobody Mon Dec 14 11:54: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 BC4FE1B2E4D for ; Mon, 14 Dec 2015 11:54:38 -0800 (PST)
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 eThoQluKmrru for ; Mon, 14 Dec 2015 11:54:36 -0800 (PST)
Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C99D11B2E4C for ; Mon, 14 Dec 2015 11:54:16 -0800 (PST)
Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id tBEJrphc018014; Mon, 14 Dec 2015 14:54:13 -0500
Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 1yrqn7c02c-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Dec 2015 14:54:12 -0500
Received: from STNTEXMB11.cis.neustar.com ([169.254.1.102]) by stntexhc10.cis.neustar.com ([169.254.4.121]) with mapi id 14.03.0158.001; Mon, 14 Dec 2015 14:54:12 -0500
From: "McGarry, Tom" 
To: "PFAUTZ, PENN L" , "modern@ietf.org" 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHRHl26DyraNZUDF0WIF1b3d5Qwlp7FC3CAgAZM7ICAAAlogP//s+EA
Date: Mon, 14 Dec 2015 19:54:11 +0000
Message-ID: 
In-Reply-To: <38726EDA2109264987B45E29E758C4D605925616@MISOUT7MSGUSRDD.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.2.130206
x-originating-ip: [10.33.205.112]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <961410AC74963C45B0E3FA2FF920D488@neustar.biz>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-12-14_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310007 definitions=main-1512140331
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 14 Dec 2015 19:54:38 -0000

WRT porting process:
This doesn't address policy.  There is no way for a user to prove to a
service provider that they do indeed have authority over the number.  It
suggests that there be a technical solution, a verifiable credential, that
a user can submit to a service provider to prove they have authority.
They have authority today, there's just no way to prove it.

WRT interconnection:
The point of that paragraph is that current numbering is highly dependent
on geography, whereas in an IP environment it would be independent of
geography.  In an IP environment it should be different.  How about
replacing the second sentence with:
"Numbering, interconnection and routing are highly dependent on geography:
the PSTN was carefully designed to delegate switching intelligence
geographically."  =20


On 12/14/15 2:26 PM, "PFAUTZ, PENN L"  wrote:

>All,
>It's statements like
>" Ideally the user would have full control of their TN and
>   would drive the porting process on their own rather than rely on
>   complex and time consuming back office processes among multiple
>   service providers."
>
>that make a policy statement which concern me.
>
>As to Tom's question, it was the statement
>" Most TNs today are assigned to specific geographies, at both an
>   international level and within national numbering plans.  This has
>   shaped the way that service providers interconnect"
>
>I think it was the reverse - numbering followed interconnection - and the
>mechanisms I need for numbering will depend on the types of
>interconnection I have to support.
>
>So, yes I do object to specifics in the document as opposed to the
>enterprise as a whole.
>
>Penn Pfautz
>AT&T Global Connection Management
>
>
>-----Original Message-----
>From: Adam Roach [mailto:adam@nostrum.com]
>Sent: Monday, December 14, 2015 1:53 PM
>To: Steve Donovan; modern@ietf.org
>Subject: Re: [Modern] Problem statement draft as working group document
>
>On 12/10/15 12:40, Steve Donovan wrote:
>> There has been no response to this so I'm going to suggest we put a
>> deadline on opinions.
>>
>> Please express your opinion on making
>> draft-peterson-modern-problems-02 a working group document before
>> Thursday, December 17th.
>>
>> It is important that anyone who supports the promotion of the document
>> also express their opinion.
>
>I think this document is a good starting point for outlining the basic
>shape of the problem and the use cases MODERN is intended to address.
>
>I'll note that on-list objections so far seem to be attempting to
>re-litigate the formation of the working group rather than making
>progress towards its milestones. As has been long established (at least
>since the 2002 formation of XMPP), the decision to work on a problem in
>the IETF is based on the following criteria: "is it technically
>credible, are people willing to work on it, are people willing to use
>it?" And, in particular: "we should be deciding things based on the
>number of folks who want to do things, not the number opposed."
>
>In terms of considering adoption of this specific document, I think we
>need to be careful to parse out objections to its contents versus
>objections to MODERN's very existence. So far, I have seen no on-list
>objections that fall in the first category.
>
>/a
>
>
>_______________________________________________
>Modern mailing list
>Modern@ietf.org
>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma=
n_
>listinfo_modern&d=3DCwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI=
DcLext
>Z1ooNcfp01IYIaVqsORjI&m=3Db8Du8PEdrEZo_LLqNvw5JrZtUM64muibjcmAAkrALxM&s=3D=
EJyT
>AVbeKglij7G7DiYeWWywwrHAbKhJQYMH8snPpFg&e=3D=20


From nobody Mon Dec 14 11:59: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 3DFFD1B2E53 for ; Mon, 14 Dec 2015 11:59:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUs-FQP8Ng2H for ; Mon, 14 Dec 2015 11:59:00 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0766.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:766]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98E191B2E54 for ; Mon, 14 Dec 2015 11:58:59 -0800 (PST)
Received: from BN1AFFO11FD053.protection.gbl (10.58.52.30) by BN1AFFO11HUB028.protection.gbl (10.58.52.138) with Microsoft SMTP Server (TLS) id 15.1.346.13; Mon, 14 Dec 2015 19:58:39 +0000
Authentication-Results: spf=pass (sender IP is 144.230.172.36) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com;
Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.36 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.36; helo=plsapdm1.corp.sprint.com;
Received: from plsapdm1.corp.sprint.com (144.230.172.36) by BN1AFFO11FD053.mail.protection.outlook.com (10.58.53.68) with Microsoft SMTP Server (TLS) id 15.1.346.13 via Frontend Transport; Mon, 14 Dec 2015 19:58:38 +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 tBEHE9n5025941;  Mon, 14 Dec 2015 13:58:38 -0600
Received: from plswe13m07.ad.sprint.com (plswe13m07.corp.sprint.com [144.229.214.26]) by plsapdm1.corp.sprint.com with ESMTP id 1yrj3g7rrg-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 14 Dec 2015 13:58:38 -0600
Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 14 Dec 2015 13:58:37 -0600
Received: from PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed]) by PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed%24]) with mapi id 15.00.1076.000; Mon, 14 Dec 2015 13:58:37 -0600
From: "Gorman, Pierce A [CTO]" 
To: "McGarry, Tom" , "PFAUTZ, PENN L" , "modern@ietf.org" 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHRHl26KCigIa6jakmAIZNM6lCGV57FC3CAgAZM7ICAAAlogP//s+EAgAAAv3A=
Date: Mon, 14 Dec 2015 19:58:36 +0000
Message-ID: 
References: <38726EDA2109264987B45E29E758C4D605925616@MISOUT7MSGUSRDD.ITServices.sbc.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.44]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD053; 1:kXbvdV4UfEEKWFCD3zHpKouEHdzDTrkFZ8yXcpkZ53aFPEc3K/l1vusN93Q1QeOmtVBm+DCVm1QYCGrhnt8Q0Lq3u7APFu4OfdSg+IH/tw3i087BTutz6De9fAAIbAvO4+PiNg3VAkp7KrzcFjbscGWP0gfM4lqc7if6BeG+ld/8JQxEAbNZqpdye/xw9sIl3LWAnxO+B7yAo/HnlPBE0xWxvTZelV81vjQBESNPaicf6mve2FU8Dq0Ap4NjuB2b06o76rSbkDkHPq6Cv1PI9fLyS7D4SxXhYKX4kRtm/I4EBDvhNTiCHwkjpkdsxi5Jb4ltrTa2jsPP8cukjHWDFhUzHyfCKDyxkSjo51y2mROY8rt3CS0D0pcXlnv22iUfXbJnfGsWNiYVfB0jQnkOfw==
X-Forefront-Antispam-Report: CIP:144.230.172.36; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(189002)(24454002)(199003)(377454003)(479174004)(13464003)(97756001)(5001770100001)(86362001)(5001960100002)(102836003)(92566002)(46406003)(81156007)(87936001)(23726003)(3846002)(97736004)(6116002)(189998001)(586003)(107886002)(2950100001)(47776003)(33646002)(108616004)(15975445007)(2900100001)(24736003)(5003600100002)(2501003)(1220700001)(6806005)(5004730100002)(50466002)(76176999)(11100500001)(5008740100001)(5250100002)(19580405001)(50986999)(106466001)(54356999)(1096002)(106116001)(19580395003)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB028; H:plsapdm1.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB028; 2:UQE4hAnvO/yMtnumN478dRrYD40S3uaVvgCytMc3Z1+Hvq/DK2ef/X+GsF4kgv4EDk3wNZTUHdAUhlh3Enr7Y1TLutDhIe2VRUSzqO02RpKVYorWWb/eJ958BN6bKPfWrjeG3584tWVh4YALo6vAwQ==; 3:DRMD49yvWTf9X2R6QfpWHIIb+tJRY00dm2fzP+MPxp3c9QimYyV0TKV6dma/gRtbB+AXYJ3yC3ZWOChRCikAa4hI5rWSzC7nTu8JTFThEBUVJ8NTqxZNLG1lIbnS6jXczv6smkVIxVv7wxiLFbAoCSU/QnuC9WNsyCoKcJXEj/NNTcSZ1r2x/DGDMX2pBGtYqpQHlBr50S6UVTk4VbZZYD4vK5lEOOjUfoh3DZ0Grvc4OBNs+fuebDWhWEqYgvXBy+NOa+z0XF31hUyP5Jvalw==; 25:18894lLt0MVVPfJzzeiWhLCCIMGoO/8yvLb9Zydi4MeZhEbYLSsbTe8Q7U6PdjU+JjhpL2186rlqCGkXJ8UAXdSo4SnRVyt04pqg2gNWXO8Uxo7j8oBTyNhS52QTu1UlGi4Xo4hPURiBtIRjdoog8Nj0T+zEUSvy0eLYBBDSDh8ReYvU+zYKclCbiUYz7fkQJu6muTYyW+h/LbkocS7y+0o1nxbL1+R0cG/p1etAFx9iSemlE3km0Foj9ROBHFW28ZGmNiRCAoqhHnNHYNu29g==
X-Exchange-Antispam-Report-Test: UriScan:; BCL:0; PCL:0; RULEID:(8251501002);  SRVR:BN1AFFO11HUB028; UriScan:(97927398514766);
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB028; 20:mEiJQO9350GW7tX2DEm/sHDTg4L6P4v1bTjCq5X2qiP/2koLOspY1tOConePsKS/p+99gC4SVX7SbHEnVjLOeimHxewD5l40Db0/tKjVY/fS/5sFjzmhTvsYWbEWPu3snUaW3keSAXSTiK5Wk9ZE8o7ORWDCr6br77m/Bm8ecFfpfNsHCme+w6xjQEomDIXVDtnMebv14ubTJUf1xoR/ZuQ8ZHDkrw5c8BCvJIQ3N1HNGmtL1eFVPdWWxk1lZLjd; 4:YQS+lsq1Uy/gYvQDGFWMv4ESszYGVHPxZuiqsyMOV2aBzQYtuNQGeeqfk8+ygD/XDOit2srAtAiJjusgBUONFNhxBZVDlqRbf/UxDNsNk5YuaumgcMJstAnaUaoXSuw+Y/WFd4UfciKxC/NH6XWNSmH0yVFsSxeDGpuTCykpSsc1oOrAEjaLu6x2v+kS+h9nOg4R0ORza/Hdjoujg1oUTfJbI66LoDqfojFXWEzZ0VWwsRRxBN3PDacpVF6y4bFein8/1txF7FKueRed6gkqYoA8V0Q61hiqsVCqAE6vWijEI2hSgRMuiScPrH18ZiUmjwMA9+n2EhYCoa1EycP2YUg+XhN9aNY8FoKohE52/9HJrDwIZzb1ocR4au65tNjoL09KmU+tqLqo0N1+fIJFABL5y30/6pSbT/DUCgSt8HHna1Lvp9Un/QnuzW9Lo3ji
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:BN1AFFO11HUB028; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB028; 
X-Forefront-PRVS: 0790FB1F33
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1AFFO11HUB028; 23:O3FKBNMrQ6U162PvOZUONTmshVZhELbb71kxq+Y?= =?us-ascii?Q?S2Ti0IjUoLZ0op68G1AA/zh8SUqrXgePOMHCa6MSbxmPkdInZJJbDsMhTpV0?= =?us-ascii?Q?GliV3I+KxRMazSN+pX+99JXJREBaokNxWEqEs3RYtgBKb5VUc0aaeDHMeGML?= =?us-ascii?Q?dZJorOe9VPhnSZdlGx0DTPndBbv0OrEOpqYHg1RZ/tAvGBwIJl4UWyTdu/Va?= =?us-ascii?Q?VFg916mWSknKy+hhfKm65tSxj0obo2s4L+zwSG/ZAYvluE43CFzaj+llIvaa?= =?us-ascii?Q?V0I+y8PErfz9iqR4tvJYRohVxZMH9vz/gdx9N9B3SgkevR3Y1hbSqkA12XyW?= =?us-ascii?Q?wGV5GFv/XikMXMfkRCCOUbkjpOyyfFItBSnp4jCzFuVQSFD+G6bfry0p7JvT?= =?us-ascii?Q?MSLfJU3lA4dq8l+ZVRqs1OcpcNBVgkt98GQkUFlnpqjpuU986tcxhL+wCgbA?= =?us-ascii?Q?VkgqqPJpCZ8LvFybSXFxzl+KYGsSo4ARIiexH7emows/YQ2fsVIaMXsYuKBl?= =?us-ascii?Q?0E9Kzu/dwN1tUNLXEDm1nemqLf27DCT9RFCbGP1qq/+C+C+iHfpxGisc8+Tr?= =?us-ascii?Q?4ESKTZLdigCUF2QZeYoSZv7WwKtnnBn0uK8UmuPun7LDPTPcpMcnfzeNJAnk?= =?us-ascii?Q?ylm1Wav57IArRevy8EzK+vdxsvc1xQRq1YQ9S43+e6zSZIoUN5nb2Hx1fKe7?= =?us-ascii?Q?vJ40Mx+cmTSxZJGQgmeFp42cA+5MjTQ3Bwq5fbioiOlzEtrgwfNhjSKhuz7+?= =?us-ascii?Q?G9uJvepBO+7TGOenLaUMAzR/SxczbHJ3tnbsyrdo/PkKYzoyaTXmyzSo45nP?= =?us-ascii?Q?vz861fwQ/yPFfYXs0J8zFRQpz0t3Wn6zB5ZahWPbhAHLCV/2w4U09vCWONHm?= =?us-ascii?Q?Ats+6fyKc6h8neCSDOdT7zQG26CFjamOy+TcqZ3ou8cNYmUqlz1TAI9WklgI?= =?us-ascii?Q?AJgGBXWCPkqIMskh/EfXnZ3bdJwERamhXqpgdYTAn5srK/TPNEU6zqri/aE/?= =?us-ascii?Q?cOdMK5dcKgLKdR219Z/2ujbK1hFR9xx2Yemhq6HPBOHb8L6G7vR0xycTthwm?= =?us-ascii?Q?oXVosPdEg8jdEE9poWgAw1sx20NsxefDSRXzfUOQdcxwxqSY2steDME+FgqE?= =?us-ascii?Q?Pd4AIEzo9u2Bfi49x3Ngvqyk1G6GuPa6F7K3uaVmIima5EJzRbpWCd905LuV?= =?us-ascii?Q?zgrJoMRww7OKDGvQJ7GTbzyAMAlkxvh18uP/luFePmKc/TxadvQYuLiuU2Ey?= =?us-ascii?Q?PkagaHC/5TUHlV/QPZCz620VopxbU70VKKnkIkEH1P8+hRa13Kkei4fV5uPk?= =?us-ascii?Q?j9iI19javJoPtg/N5CPF92uM=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB028; 5:CFMkTnGj3X1GbzraJuvQ121dOqZrjl9KTYIzVksZE5ylruGYL/7eT3j0DxXHFV1yj3S14UzQHeX+aUXoT0v5I8sEcrpXuJZ6mwsvQokephtNf6aZpeD3rb3N/6OI/wIEtBJhknMR9gjMIU2AwOEnzQ==; 24:bfLXGNSfwQBAdd83K+Bf4dhIhSCsJ+PPZW/MO2IwPC0mZAFc+QdqQPIjARgWglMX5flEP9/SiXpihHYXooggVlynA7d1GW58MrbeQ7XpXaM=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: sprint.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Dec 2015 19:58:38.9749 (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: BN1AFFO11HUB028
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 14 Dec 2015 19:59:05 -0000

Replace "Numbering, interconnection and routing are highly dependent on geo=
graphy: the PSTN was carefully designed to delegate switching intelligence =
geographically."

With " Numbering, interconnection and routing are CURRENTLY highly dependen=
t on geography:  the PSTN NUMBERING AUTHORITY was carefully designed to del=
egate NUMBERING AUTHORITY geographically.


-----Original Message-----
From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: December 14, 2015 1:54 PM
To: PFAUTZ, PENN L ; modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

WRT porting process:
This doesn't address policy.  There is no way for a user to prove to a serv=
ice provider that they do indeed have authority over the number.  It sugges=
ts that there be a technical solution, a verifiable credential, that a user=
 can submit to a service provider to prove they have authority.
They have authority today, there's just no way to prove it.

WRT interconnection:
The point of that paragraph is that current numbering is highly dependent o=
n geography, whereas in an IP environment it would be independent of geogra=
phy.  In an IP environment it should be different.  How about replacing the=
 second sentence with:
"Numbering, interconnection and routing are highly dependent on geography:
the PSTN was carefully designed to delegate switching intelligence
geographically."


On 12/14/15 2:26 PM, "PFAUTZ, PENN L"  wrote:

>All,
>It's statements like
>" Ideally the user would have full control of their TN and
>   would drive the porting process on their own rather than rely on
>   complex and time consuming back office processes among multiple
>   service providers."
>
>that make a policy statement which concern me.
>
>As to Tom's question, it was the statement " Most TNs today are
>assigned to specific geographies, at both an
>   international level and within national numbering plans.  This has
>   shaped the way that service providers interconnect"
>
>I think it was the reverse - numbering followed interconnection - and
>the mechanisms I need for numbering will depend on the types of
>interconnection I have to support.
>
>So, yes I do object to specifics in the document as opposed to the
>enterprise as a whole.
>
>Penn Pfautz
>AT&T Global Connection Management
>
>
>-----Original Message-----
>From: Adam Roach [mailto:adam@nostrum.com]
>Sent: Monday, December 14, 2015 1:53 PM
>To: Steve Donovan; modern@ietf.org
>Subject: Re: [Modern] Problem statement draft as working group document
>
>On 12/10/15 12:40, Steve Donovan wrote:
>> There has been no response to this so I'm going to suggest we put a
>> deadline on opinions.
>>
>> Please express your opinion on making
>> draft-peterson-modern-problems-02 a working group document before
>> Thursday, December 17th.
>>
>> It is important that anyone who supports the promotion of the
>> document also express their opinion.
>
>I think this document is a good starting point for outlining the basic
>shape of the problem and the use cases MODERN is intended to address.
>
>I'll note that on-list objections so far seem to be attempting to
>re-litigate the formation of the working group rather than making
>progress towards its milestones. As has been long established (at least
>since the 2002 formation of XMPP), the decision to work on a problem in
>the IETF is based on the following criteria: "is it technically
>credible, are people willing to work on it, are people willing to use
>it?" And, in particular: "we should be deciding things based on the
>number of folks who want to do things, not the number opposed."
>
>In terms of considering adoption of this specific document, I think we
>need to be careful to parse out objections to its contents versus
>objections to MODERN's very existence. So far, I have seen no on-list
>objections that fall in the first category.
>
>/a
>
>
>_______________________________________________
>Modern mailing list
>Modern@ietf.org
>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm
>an_
>listinfo_modern&d=3DCwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI=
DcL
>ext
>Z1ooNcfp01IYIaVqsORjI&m=3Db8Du8PEdrEZo_LLqNvw5JrZtUM64muibjcmAAkrALxM&s=3D=
E
>JyT AVbeKglij7G7DiYeWWywwrHAbKhJQYMH8snPpFg&e=3D

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

________________________________

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


From nobody Mon Dec 14 12:08:51 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93941B2E83 for ; Mon, 14 Dec 2015 12:08:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.277
X-Spam-Level: 
X-Spam-Status: No, score=-0.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-yjYf9zPKaB for ; Mon, 14 Dec 2015 12:08:45 -0800 (PST)
Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EBC81B2E7B for ; Mon, 14 Dec 2015 12:08:45 -0800 (PST)
Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id tBEK8A1t021304; Mon, 14 Dec 2015 15:08:44 -0500
Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1yrqn7c1kr-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Dec 2015 15:08:44 -0500
Received: from STNTEXMB11.cis.neustar.com ([169.254.1.102]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Mon, 14 Dec 2015 15:08:43 -0500
From: "McGarry, Tom" 
To: "Gorman, Pierce A [CTO]" 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHRHl26DyraNZUDF0WIF1b3d5Qwlp7FC3CAgABrkwCABZwMgIAAEsgAgAAjGgD//7V3AIAAV56AgAAP6QD//7PHgA==
Date: Mon, 14 Dec 2015 20:08:42 +0000
Message-ID: 
In-Reply-To: <76318e83d917441c8843bed9f11e901b@PLSWE13M08.ad.sprint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.2.130206
x-originating-ip: [10.33.205.112]
Content-Type: multipart/alternative; boundary="_000_D2948AF432E74tommcgarryneustarbiz_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-12-14_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310007 definitions=main-1512140334
Archived-At: 
Cc: "modern@ietf.org" 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 14 Dec 2015 20:08:49 -0000

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

See comments inline.

From: , Pierce Gorman >
Date: Monday, December 14, 2015 2:41 PM
To: Martin Dolly >, Tom Mcgarry >
Cc: Modern List >, "PFAUTZ, PENN L"=
 >
Subject: RE: [Modern] Problem statement draft as working group document

Not sure where I=92m allowed to start listing objections and which would be=
 considered substantive and which would be considered irrelevant nits, but =
I=92ll offer a few now and add as time and interest permits.


In Section 1 Problem Statement I object to the assertion, =93The original E=
NUM concept of a single root, e164.arpa, proved to be politically challengi=
ng, and less centralized models have thus flourished.=94  The fundamental p=
roblem was not that ENUM was =93politically challenging=93.  ENUM was also =
practically challenging, on multiple levels.

TOM: How about "politically and practically challenging"



First and foremost, ENUM in e164.arpa had no concept that route selection c=
ould not simply be made based on where a terminating number was being serve=
d from.  Route selection had to almost always also be based on the type of =
number that was being called and where a call was originating from.  The or=
iginal DNS-only ENUM approach failed to accomodate those requirements.



The less-centralized models didn=92t flourish because of a lack of politica=
l challenges.  They flourished because proprietary non-DNS database impleme=
ntations which used the DNS resource record query/response protocols overca=
me fundamental limitations of a strictly e164.arpa implementation.



Another assertion I find objectionable is, =93Telephone numbering, however,=
 has long been transitioning away from a provider-centric model towards a u=
ser-centric model.=94  The example of number portability overlooks the fact=
 that the ported number is assigned a pointer back into a provider-centric =
model of routing information domestically known as the LERG.



It goes on to say, =93Thanks to the increasing sophistication of consumer m=
obile devices, users now associate TNs with many applications other than te=
lephony.=94 So the assertion is made that (mobile) users (of smart phones) =
can easily associate services with their telephone numbers.  No argument.  =
How is this a problem?

TOM:  No problem.



Next the argument is made that, =93Ideally the user would have full control=
 of their TN and would drive the porting process on their own rather than r=
ely on complex and time consuming back office processes among multiple serv=
ice providers.=93  This is interesting.  Who has control over a TN being po=
rted if not the end user?

TOM:  See my response to Penn's email.



Is the thought that the user no longer would require the services of a serv=
ice provider?



Or is it that service providers will constantly troll the MODERN database l=
ooking for users who=92ve selected them to be their service provider?



How would the losing SP (if there is one), learn they=92ve been de-selected=
?



How does the commercial relationship between the new SP and the user get es=
tablished?  Careful, it might look like an awful lot like a =93complex and =
time consuming back office=94 process.



Will this new method of self-registration and de-registration, and commerci=
al relationship establishment somehow gain material benefit over the existi=
ng =93complex and time consuming back office processes among multiple servi=
ce providers=93?



What was the problem or problems that were solved?  Do users really care ab=
out the complexity of a change between service provider back-office systems=
? How could they?  They have no visibility to it other than the caveat that=
 it might take a few hours before the port was complete.  What is the avera=
ge time for port completion?  Is there really a problem here to solve?  Wha=
t will that port time look like after the conversion from the current NP pr=
ovider (domestically) and the new NP provider?  Is porting a problem intern=
ationally?  Is MODERN going to fix international  porting problems?



And, I can=92t let it go unsaid that the claim end users are harmed by =93c=
omplex and time consuming back office processes among multiple service prov=
iders=94 ignores the fact that the service providers are forced to rely on =
systems developed and managed through a regulated back-office provider whic=
h frankly seems somewhat disingenuous given who is advancing the arguments.

Pierce Gorman
From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C
Sent: December 14, 2015 12:45 PM
To: McGarry, Tom >
Cc: modern@ietf.org; PFAUTZ, PENN L >
Subject: Re: [Modern] Problem statement draft as working group document

Number assignment to users has been an is from day 1.
If there was no Interconnection, none of this would be relevant

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: 609-903-3360
Email: md3135@att.com

On Dec 14, 2015, at 1:31 PM, McGarry, Tom > wrote:
Thanks Penn.

I don't understand your point about numbering vs interconnection.  Is there=
 something in the document you can point to?

Also can you point me to the statements about user and SP roles?

From: , PENN L >
Date: Monday, December 14, 2015 12:57 PM
To: Pierce Gorman >, Steve Donovan >, Modern List >
Subject: Re: [Modern] Problem statement draft as working group document

I find that I need to object as well. It is not numbering that drives inter=
connection so much as interconnection drives numbering. As the evolution of=
 interconnection even as the PSTN migrates to an IP backbone is by no means=
 settled I=92m concerned that we are getting the cart before the horse. I a=
lso object to the conclusory statements about user and service provider rol=
es; I think the picture is more complicated.
I remain sympathetic to the goal of modernizing number administration and r=
outing but the document is problematic for me.

Penn Pfautz
AT&T Global Connection Management


From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com]
Sent: Monday, December 14, 2015 10:52 AM
To: Steve Donovan; modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

If an actual reason is not required I would like to add my vote of dissensi=
on on principal without having to actually read the =93draft-peterson-moder=
n-problems-02=94.  You might recall I argued with the language in the chart=
er but I and others were over-ruled by the Area Directors.

Pierce Gorman

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: December 14, 2015 8:45 AM
To: modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

Eric,

Could you elaborate on why you think the document should not become a worki=
ng group item.
Thanks,

Steve
On 12/10/15 7:05 PM, Eric Burger wrote:

Nah. :-)



On Dec 10, 2015, at 1:40 PM, Steve Donovan  wrote:



There has been no response to this so I'm going to suggest we put a deadlin=
e on opinions.



Please express your opinion on making draft-peterson-modern-problems-02 a w=
orking group document before Thursday, December 17th.



It is important that anyone who supports the promotion of the document also=
 express their opinion.



Thanks,



Steve



On 11/13/15 3:53 PM, Steve Donovan wrote:

All,



During the IETF94 MODERN WG meeting there was consensus that draft-peterson=
-modern-problems-02 be accepted as a working group document.  This would be=
 to address the architecture Architecture Overview milestone.



It was recognized that it is not in final form but would be a good starting=
 point for the architecture overview.



Please comment on whether or not this should become a working group documen=
t.



Regards,



Steve



_______________________________________________

Modern mailing list

Modern@ietf.org

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



_______________________________________________

Modern mailing list

Modern@ietf.org

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






_______________________________________________

Modern mailing list

Modern@ietf.org

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


________________________________

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

________________________________

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

--_000_D2948AF432E74tommcgarryneustarbiz_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







See comments inline.  









From: <Gorman>, Pierce Gorman=
 <Pierce.Gorman@sprint.com>

Date: Monday, December 14, 2015 2:4=
1 PM

To: Martin Dolly <md3135@att.com>, Tom Mcgarry <tom.mcgarry@neustar.biz>

Cc: Modern List <modern@ietf.org>, "PFAUTZ, PENN L" <=
;pp3129@att.com>

Subject: RE: [Modern] Problem state=
ment draft as working group document

















Not sure where I=92m allowed to start =
listing objections and which would be considered substantive and which woul=
d be considered irrelevant nits, but I=92ll
 offer a few now and add as time and interest permits.

 


In Section 1 Problem Statement I object to the assertion=
, =93The original ENUM concept of a=
 single root, e164.arpa, proved to be politically challenging, and less cen=
tralized models have thus flourished.=94  The fun=
damental problem was not that ENUM was =93politically challenging=93.  ENUM was also=
 practically challenging, on multiple levels.














TOM: How about "politically and practical=
ly challenging"











 


First and foremost, ENUM in e164.arpa had no concept tha=
t route selection could not simply be made based on where a terminating num=
ber was being served from.  Route selection had to almost always also =
be based on the type of number that was being called and where a call was o=
riginating from.  The original DNS-only ENUM approach failed to accomo=
date those requirements.


 


The less-centralized models didn=92t flourish because of=
 a lack of political challenges.  They flourished because proprietary =
non-DNS database implementations which used the DNS resource record query/r=
esponse protocols overcame fundamental limitations of a strictly e164.arpa =
implementation.


 


Another assertion I find objectionable is, =93Telephone numbering, however, has long been t=
ransitioning away from a provider-centric model towards a user-centric mode=
l.=94  The example of number portability overlook=
s the fact that the ported number is assigned a pointer back into a provide=
r-centric model of routing information domestically known as the LERG.=



 


It goes on to say, =93Thanks to the increasing sophistication of consumer mobile devices, u=
sers now associate TNs with many applications other than telephony.=94 So the assertion is made that (mobile) users (of smart pho=
nes) can easily associate services with their telephone numbers.  No a=
rgument.  How is this a problem?














TOM:  No problem.  











 


Next the argument is made that, =93Ideally the user would have full control of their TN and=
 would drive the porting process on their own rather than rely on complex a=
nd time consuming back office processes among multiple service providers.=93  This is interesting.  Who has control ove=
r a TN being ported if not the end user?














TOM:  See my response to Penn's email.  











 


Is the thought that the user no longer would require the=
 services of a service provider?


 


Or is it that service providers will constantly troll th=
e MODERN database looking for users who=92ve selected them to be their serv=
ice provider?


 


How would the losing SP (if there is one), learn they=92=
ve been de-selected?


 


How does the commercial relationship between the new SP =
and the user get established?  Careful, it might look like an awful lo=
t like a =93complex and time consum=
ing back office=94 process.


 


Will this new method of self-registration and de-registr=
ation, and commercial relationship establishment somehow gain material bene=
fit over the existing =93complex an=
d time consuming back office processes among multiple service providers=93?


 


What was the problem or problems that were solved? =
 Do users really care about the complexity of a change between service prov=
ider back-office systems? How could they?  They have no visibility to =
it other than the caveat that it might take a few hours before the port was=
 complete.  What is the average time for port completion?  Is the=
re really a problem here to solve?  What will that port time look like=
 after the conversion from the current NP provider (domestically) and the n=
ew NP provider?  Is porting a problem internationally?  Is MODERN=
 going to fix international  porting problems?


 


And, I can=92t let it go unsaid that the claim end users=
 are harmed by =93complex and time =
consuming back office processes among multiple service providers=94 ignores the fact that the service providers are forced to rel=
y on systems developed and managed through a regulated back-office provider=
 which frankly seems somewhat disingenuous given who is advancing the argum=
ents.


 


Pierce Gorman






From: Modern [=
mailto:modern-bounces@ietf.org]
On Behalf Of DOLLY, MARTIN C

Sent: December 14, 2015 12:45 PM

To: McGarry, Tom <Tom.=
McGarry@neustar.biz>

Cc: modern@ietf.org; PFAUTZ, =
PENN L <pp3129@att.com>

Subject: Re: [Modern] Problem statement draft as working group docum=
ent






 




Number assignment to users has been an is from day 1=
. 






If there was no Interconnection, none of this would =
be relevant 



Martin C Dolly 




Lead Member of Technical Staff






Core & Government/Regulatory Standards 






AT&T






Cell: 609-903-3360











On Dec 14, 2015, at 1:31 PM, McGarry, Tom <Tom.McGarry@neustar.biz> wrote:










Thanks Penn.  






 






I don't understand your point about numbering vs int=
erconnection.  Is there something in the document you can point to?






 






Also can you point me to the statements about user a=
nd SP roles?   






 






From:
<PFAUTZ>, PENN L <pp3129@att=
.com>

Date: Monday, December 14, 2015 12:57 PM

To: Pierce Gorman <Pi=
erce.Gorman@sprint.com>, Steve Donovan <srdonovan@usdonovans.com>, Modern List <modern@ietf.org>

Subject: Re: [Modern] Problem statement draft as working group docum=
ent






 








I find that I need to object as we=
ll. It is not numbering that drives interconnection so much as interconnect=
ion drives numbering. As the evolution
 of interconnection even as the PSTN migrates to an IP backbone is by no me=
ans settled I=92m concerned that we are getting the cart before the horse. =
I also object to the conclusory statements about user and service provider =
roles; I think the picture is more
 complicated.


I remain sympathetic to the goal o=
f modernizing number administration and routing but the document is problem=
atic for me.


 


Penn Pfautz


AT&T Global Connection Managem=
ent


 


 






From: Gorman, =
Pierce A [CTO] [mailto:Pierce.G=
orman@sprint.com]


Sent: Monday, December 14, 2015 10:52 AM

To: Steve Donovan; modern@ietf.or=
g

Subject: Re: [Modern] Problem statement draft as working group docum=
ent






 


If an actual reason is not required I =
would like to add my vote of dissension on principal without having to actu=
ally read the =93draft-peterson-modern-problems-02=94.=
 
 You might recall I argued with the language in the charter but I and other=
s were over-ruled by the Area Directors.


 


Pierce Gorman


 






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

Sent: December 14, 2015 8:45 AM

To: modern@ietf.org

Subject: Re: [Modern] Problem statement draft as working group docum=
ent






 


Eric,



Could you elaborate on why you think the document should not become a worki=
ng group item.


Thanks,



Steve




On 12/10/15 7:05 PM, Eric Burger wrote:





Nah. :-)


 




On Dec 10, 2015, at 1:40 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 


There has been no response to this so I'm going to suggest we put a de=
adline on opinions.


 


Please express your opinion on making draft-peterson-modern-problems-0=
2 a working group document before Thursday, December 17th.


 


It is important that anyone who supports the promotion of the document=
 also express their opinion.


 


Thanks,


 


Steve


 


On 11/13/15 3:53 PM, Steve Donovan wrote:




All,


 


During the IETF94 MODERN WG meeting there was consensus that draft-pet=
erson-modern-problems-02 be accepted as a working group document.  Thi=
s would be to address the architecture Architecture Overview milestone.


 


It was recognized that it is not in final form but would be a good sta=
rting point for the architecture overview.


 


Please comment on whether or not this should become a working group do=
cument.


 


Regards,


 


Steve


 


_______________________________________________


Modern mailing list


Modern@ietf.org

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




 


_______________________________________________


Modern mailing list


Modern@ietf.org

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




 











_______________________________________________


Modern mailing list


Modern@ietf.org

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




 


 <=
/o:p>










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














___________________=
____________________________

Modern mailing list

Modern@ietf.org

https://www.ietf.org/mailman/listinfo/modern<=
/span>













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


From nobody Mon Dec 14 12:10: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 E56561B2E6B for ; Mon, 14 Dec 2015 12:10:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AySYtOWH3t3A for ; Mon, 14 Dec 2015 12:10:15 -0800 (PST)
Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8B551B2E63 for ; Mon, 14 Dec 2015 12:10:14 -0800 (PST)
Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id tBEK65iR026724; Mon, 14 Dec 2015 15:10:10 -0500
Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 1yrqn7c16c-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Dec 2015 15:10:09 -0500
Received: from STNTEXMB11.cis.neustar.com ([169.254.1.102]) by stntexhc10.cis.neustar.com ([169.254.4.121]) with mapi id 14.03.0158.001; Mon, 14 Dec 2015 15:10:09 -0500
From: "McGarry, Tom" 
To: "Gorman, Pierce A [CTO]" , "modern@ietf.org" 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHRHl26DyraNZUDF0WIF1b3d5Qwlp7FC3CAgAZM7ICAAAlogP//s+EAgABVEwD//69hAA==
Date: Mon, 14 Dec 2015 20:10:09 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.2.130206
x-originating-ip: [10.33.205.112]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-12-14_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310007 definitions=main-1512140334
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 14 Dec 2015 20:10:17 -0000

You seem to be trying to make a different point - one about numbering
authorities.  The original point is about network architecture.

On 12/14/15 2:58 PM, "Gorman, Pierce A [CTO]" 
wrote:

>Replace "Numbering, interconnection and routing are highly dependent on
>geography: the PSTN was carefully designed to delegate switching
>intelligence geographically."
>
>With " Numbering, interconnection and routing are CURRENTLY highly
>dependent on geography:  the PSTN NUMBERING AUTHORITY was carefully
>designed to delegate NUMBERING AUTHORITY geographically.
>
>
>-----Original Message-----
>From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
>Sent: December 14, 2015 1:54 PM
>To: PFAUTZ, PENN L ; modern@ietf.org
>Subject: Re: [Modern] Problem statement draft as working group document
>
>WRT porting process:
>This doesn't address policy.  There is no way for a user to prove to a
>service provider that they do indeed have authority over the number.  It
>suggests that there be a technical solution, a verifiable credential,
>that a user can submit to a service provider to prove they have authority.
>They have authority today, there's just no way to prove it.
>
>WRT interconnection:
>The point of that paragraph is that current numbering is highly dependent
>on geography, whereas in an IP environment it would be independent of
>geography.  In an IP environment it should be different.  How about
>replacing the second sentence with:
>"Numbering, interconnection and routing are highly dependent on geography:
>the PSTN was carefully designed to delegate switching intelligence
>geographically."
>
>
>On 12/14/15 2:26 PM, "PFAUTZ, PENN L"  wrote:
>
>>All,
>>It's statements like
>>" Ideally the user would have full control of their TN and
>>   would drive the porting process on their own rather than rely on
>>   complex and time consuming back office processes among multiple
>>   service providers."
>>
>>that make a policy statement which concern me.
>>
>>As to Tom's question, it was the statement " Most TNs today are
>>assigned to specific geographies, at both an
>>   international level and within national numbering plans.  This has
>>   shaped the way that service providers interconnect"
>>
>>I think it was the reverse - numbering followed interconnection - and
>>the mechanisms I need for numbering will depend on the types of
>>interconnection I have to support.
>>
>>So, yes I do object to specifics in the document as opposed to the
>>enterprise as a whole.
>>
>>Penn Pfautz
>>AT&T Global Connection Management
>>
>>
>>-----Original Message-----
>>From: Adam Roach [mailto:adam@nostrum.com]
>>Sent: Monday, December 14, 2015 1:53 PM
>>To: Steve Donovan; modern@ietf.org
>>Subject: Re: [Modern] Problem statement draft as working group document
>>
>>On 12/10/15 12:40, Steve Donovan wrote:
>>> There has been no response to this so I'm going to suggest we put a
>>> deadline on opinions.
>>>
>>> Please express your opinion on making
>>> draft-peterson-modern-problems-02 a working group document before
>>> Thursday, December 17th.
>>>
>>> It is important that anyone who supports the promotion of the
>>> document also express their opinion.
>>
>>I think this document is a good starting point for outlining the basic
>>shape of the problem and the use cases MODERN is intended to address.
>>
>>I'll note that on-list objections so far seem to be attempting to
>>re-litigate the formation of the working group rather than making
>>progress towards its milestones. As has been long established (at least
>>since the 2002 formation of XMPP), the decision to work on a problem in
>>the IETF is based on the following criteria: "is it technically
>>credible, are people willing to work on it, are people willing to use
>>it?" And, in particular: "we should be deciding things based on the
>>number of folks who want to do things, not the number opposed."
>>
>>In terms of considering adoption of this specific document, I think we
>>need to be careful to parse out objections to its contents versus
>>objections to MODERN's very existence. So far, I have seen no on-list
>>objections that fall in the first category.
>>
>>/a
>>
>>
>>_______________________________________________
>>Modern mailing list
>>Modern@ietf.org
>>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm
>>an_
>>listinfo_modern&d=3DCwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufvee=
IDcL
>>ext
>>Z1ooNcfp01IYIaVqsORjI&m=3Db8Du8PEdrEZo_LLqNvw5JrZtUM64muibjcmAAkrALxM&s=
=3DE
>>JyT AVbeKglij7G7DiYeWWywwrHAbKhJQYMH8snPpFg&e=3D
>
>_______________________________________________
>Modern mailing list
>Modern@ietf.org
>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma=
n_
>listinfo_modern&d=3DCwIFAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI=
DcLext
>Z1ooNcfp01IYIaVqsORjI&m=3DwX7NaCp4TR1we4d444AWJk4h5Znti2aqix5Cr5-fxCY&s=3D=
ol3y
>MdIchtzVnkdtU27FYlKIZ0SFMiXd-GbOP0BEn08&e=3D
>
>________________________________
>
>This e-mail may contain Sprint proprietary information intended for the
>sole use of the recipient(s). Any use by others is prohibited. If you are
>not the intended recipient, please contact the sender and delete all
>copies of the message.


From nobody Mon Dec 14 12:46:44 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102341B2EE9 for ; Mon, 14 Dec 2015 12:46:43 -0800 (PST)
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 VEsvggQPyBPd for ; Mon, 14 Dec 2015 12:46:40 -0800 (PST)
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 609021B2EEC for ; Mon, 14 Dec 2015 12:46:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1450125980; x=1481661980; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=cl472tptfG1EEAnzoIs9t952gR2AU7RhEHv4kOZraWs=; b=uLkYwTS8sH9grNQAdQRLX0o85eyhjHkvKebQUKodCEjfDGWuQagUpHc1 xz6LqUwhT6UbP4AJNl2wABvZEwgZS0FneXe7m4BdTlAt63KTiRVOFdamU vMNx5fwu/IyVrx518dophRGYVZkpV5CHdSiLjhGY3pUduolYx2gJzbF/p U=;
X-IronPort-Anti-Spam-Filtered: false
Received: from omzsmtpi01.vzbi.com ([165.122.46.171]) by omzsmtpe03.verizonbusiness.com with ESMTP; 14 Dec 2015 20:46:19 +0000
From: "Dwight, Timothy M (Tim)" 
X-IronPort-AV: E=Sophos;i="5.20,428,1444694400"; d="scan'208";a="559001347"
Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by omzsmtpi01.vzbi.com with ESMTP; 14 Dec 2015 20:46:16 +0000
Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Mon, 14 Dec 2015 15:46:16 -0500
To: "McGarry, Tom" , "Gorman, Pierce A [CTO]" , "modern@ietf.org" 
Date: Mon, 14 Dec 2015 15:46:15 -0500
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHRHl26DyraNZUDF0WIF1b3d5Qwlp7FC3CAgAZM7ICAAAlogP//s+EAgABVEwD//69hAIAAAnfg
Message-ID: <2B0F677F0B95454297753F58D4A07FA30282E7193A@FHDP1LUMXC7V31.us.one.verizon.com>
References:  
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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 14 Dec 2015 20:46:43 -0000

Tom,

What I think you're saying is that the function of a telephone number in an=
 "all IP world" is expected to be different than in the PSTN. =20

Telephone numbers are used for routing in the PSTN, which is the fundamenta=
l reason their assignment generally reflects the topology of the network.  =
 The PSTN routes on number prefixes, as does the Internet.  There are diffe=
rences in the details, but the fundamental need for address summarization i=
s common.  This results in address assignments that reflect network topolog=
y.

I *think* the reason for the assumption that telephone number assignment in=
 an all-IP world need not reflect geography is that it's assumed that telep=
hone numbers in that environment are no longer treated as addresses.   Inst=
ead they are generally expected to be identifiers, mapped to network addres=
ses through some sort of translation process.  Right?

If so I would buy that the rationale for embedding geography into telephone=
 numbers, in an "all IP world", is different than it has been in the PSTN. =
 I don't think it's gone though.  As a simple example, we will probably nee=
d to maintain the notion of a "country code", because telephone numbers are=
 national resources and subject to national laws and regulation.  It might =
also be that within a country, number assignment is performed by agencies r=
esponsible for certain geographic areas.  It seems technically possible tha=
t they all share a single pool of numbers, but some countries might elect n=
ot to.  They might prefer instead to partition the address space.  Such par=
titioning would be reflected in the addresses they assign.   So I think it'=
s plausible we could see some amount of geography reflected in the telephon=
e number, just due to the way they're assigned.  That's how I interpreted P=
ierce's comments earlier.

Cheers,

tim

-----Original Message-----
From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: Monday, December 14, 2015 2:10 PM
To: Gorman, Pierce A [CTO]; modern@ietf.org
Subject: [E] Re: [Modern] Problem statement draft as working group document

You seem to be trying to make a different point - one about numbering autho=
rities.  The original point is about network architecture.

On 12/14/15 2:58 PM, "Gorman, Pierce A [CTO]" 
wrote:

>Replace "Numbering, interconnection and routing are highly dependent on
>geography: the PSTN was carefully designed to delegate switching=20
>intelligence geographically."
>
>With " Numbering, interconnection and routing are CURRENTLY highly=20
>dependent on geography:  the PSTN NUMBERING AUTHORITY was carefully=20
>designed to delegate NUMBERING AUTHORITY geographically.
>
>
>-----Original Message-----
>From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
>Sent: December 14, 2015 1:54 PM
>To: PFAUTZ, PENN L ; modern@ietf.org
>Subject: Re: [Modern] Problem statement draft as working group document
>
>WRT porting process:
>This doesn't address policy.  There is no way for a user to prove to a=20
>service provider that they do indeed have authority over the number. =20
>It suggests that there be a technical solution, a verifiable=20
>credential, that a user can submit to a service provider to prove they hav=
e authority.
>They have authority today, there's just no way to prove it.
>
>WRT interconnection:
>The point of that paragraph is that current numbering is highly=20
>dependent on geography, whereas in an IP environment it would be=20
>independent of geography.  In an IP environment it should be different. =20
>How about replacing the second sentence with:
>"Numbering, interconnection and routing are highly dependent on geography:
>the PSTN was carefully designed to delegate switching intelligence=20
>geographically."
>
>
>On 12/14/15 2:26 PM, "PFAUTZ, PENN L"  wrote:
>
>>All,
>>It's statements like
>>" Ideally the user would have full control of their TN and
>>   would drive the porting process on their own rather than rely on
>>   complex and time consuming back office processes among multiple
>>   service providers."
>>
>>that make a policy statement which concern me.
>>
>>As to Tom's question, it was the statement " Most TNs today are=20
>>assigned to specific geographies, at both an
>>   international level and within national numbering plans.  This has
>>   shaped the way that service providers interconnect"
>>
>>I think it was the reverse - numbering followed interconnection - and=20
>>the mechanisms I need for numbering will depend on the types of=20
>>interconnection I have to support.
>>
>>So, yes I do object to specifics in the document as opposed to the=20
>>enterprise as a whole.
>>
>>Penn Pfautz
>>AT&T Global Connection Management
>>
>>
>>-----Original Message-----
>>From: Adam Roach [mailto:adam@nostrum.com]
>>Sent: Monday, December 14, 2015 1:53 PM
>>To: Steve Donovan; modern@ietf.org
>>Subject: Re: [Modern] Problem statement draft as working group=20
>>document
>>
>>On 12/10/15 12:40, Steve Donovan wrote:
>>> There has been no response to this so I'm going to suggest we put a=20
>>> deadline on opinions.
>>>
>>> Please express your opinion on making
>>> draft-peterson-modern-problems-02 a working group document before=20
>>> Thursday, December 17th.
>>>
>>> It is important that anyone who supports the promotion of the=20
>>> document also express their opinion.
>>
>>I think this document is a good starting point for outlining the basic=20
>>shape of the problem and the use cases MODERN is intended to address.
>>
>>I'll note that on-list objections so far seem to be attempting to=20
>>re-litigate the formation of the working group rather than making=20
>>progress towards its milestones. As has been long established (at=20
>>least since the 2002 formation of XMPP), the decision to work on a=20
>>problem in the IETF is based on the following criteria: "is it=20
>>technically credible, are people willing to work on it, are people=20
>>willing to use it?" And, in particular: "we should be deciding things=20
>>based on the number of folks who want to do things, not the number oppose=
d."
>>
>>In terms of considering adoption of this specific document, I think we=20
>>need to be careful to parse out objections to its contents versus=20
>>objections to MODERN's very existence. So far, I have seen no on-list=20
>>objections that fall in the first category.
>>
>>/a
>>
>>
>>_______________________________________________
>>Modern mailing list
>>Modern@ietf.org
>>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail
>>m
>>an_
>>listinfo_modern&d=3DCwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufvee=
IDc
>>L
>>ext
>>Z1ooNcfp01IYIaVqsORjI&m=3Db8Du8PEdrEZo_LLqNvw5JrZtUM64muibjcmAAkrALxM&s=
=3D
>>E JyT AVbeKglij7G7DiYeWWywwrHAbKhJQYMH8snPpFg&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=3DCwIFAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI=
DcL
>ext=20
>Z1ooNcfp01IYIaVqsORjI&m=3DwX7NaCp4TR1we4d444AWJk4h5Znti2aqix5Cr5-fxCY&s=3D=
o
>l3y MdIchtzVnkdtU27FYlKIZ0SFMiXd-GbOP0BEn08&e=3D
>
>________________________________
>
>This e-mail may contain Sprint proprietary information intended for the=20
>sole use of the recipient(s). Any use by others is prohibited. If you=20
>are not the intended recipient, please contact the sender and delete=20
>all copies of the message.

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


From nobody Mon Dec 14 13:17:40 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9F81B2F66 for ; Mon, 14 Dec 2015 13:17:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpykpFPHMEAQ for ; Mon, 14 Dec 2015 13:17:34 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0147.outbound.protection.outlook.com [65.55.169.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AF2A1A0100 for ; Mon, 14 Dec 2015 13:17:34 -0800 (PST)
Received: from BL2FFO11FD047.protection.gbl (10.173.160.30) by BL2FFO11HUB030.protection.gbl (10.173.161.54) with Microsoft SMTP Server (TLS) id 15.1.346.13; Mon, 14 Dec 2015 21:17:32 +0000
Authentication-Results: spf=pass (sender IP is 144.230.172.36) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com;
Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.36 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.36; helo=plsapdm1.corp.sprint.com;
Received: from plsapdm1.corp.sprint.com (144.230.172.36) by BL2FFO11FD047.mail.protection.outlook.com (10.173.161.209) with Microsoft SMTP Server (TLS) id 15.1.346.13 via Frontend Transport; Mon, 14 Dec 2015 21:17:32 +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 tBEK75lc025544;  Mon, 14 Dec 2015 15:17:31 -0600
Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by plsapdm1.corp.sprint.com with ESMTP id 1yrj3g8dq4-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 14 Dec 2015 15:17:31 -0600
Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M07.ad.sprint.com (2002:90e2:801a::90e2:801a) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 14 Dec 2015 16:17:30 -0500
Received: from PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed]) by PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed%24]) with mapi id 15.00.1076.000; Mon, 14 Dec 2015 15:17:30 -0600
From: "Gorman, Pierce A [CTO]" 
To: "McGarry, Tom" , "modern@ietf.org" 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHRHl26KCigIa6jakmAIZNM6lCGV57FC3CAgAZM7ICAAAlogP//s+EAgAAAv3CAAGhSgP//m51w
Date: Mon, 14 Dec 2015 21:17:29 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.214.116.44]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD047; 1:Osbe3+YzkCfsKGidHMF5GaSOo969jXoxWA8IZdPcWI5FkO92J1wynfYWeXtm4CLDMWU3pFByyKAJqJcSK6F79QxzWHTjirqST5GScN51K90x/FmrcvwsAhgkBZt0vn83mRtwW+e24KtBlVDQcltdYkh798xc2wvKf1GgFdHZp7GtdmE6NewsJH0lXwcAepmX4C8kR7m/+Y412N5LQQ7DjPLJwEhMv5OHT9vz08++etYmMq09SkrDgLvjF3qYZEWcX19hFz7y7E4T5/zD8FgN0oIIrwXORXlCiOPqUJlXqcRB3rPKaSzTMXPs/tgFupOgbMw/6VMMjVWowDLkh79BlIX3p+bkjq+S0K+C7ydKhIipvXRMZB4vLZIGKEXM3vKyANHq5L4zv0LlxC2e/9XRnw==
X-Forefront-Antispam-Report: CIP:144.230.172.36; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(377454003)(24454002)(13464003)(479174004)(199003)(189002)(81156007)(11100500001)(189998001)(108616004)(5001960100002)(5003600100002)(5001770100001)(107886002)(33646002)(97756001)(1096002)(102836003)(3846002)(23726003)(86362001)(1220700001)(6116002)(47776003)(2900100001)(87936001)(575784001)(106466001)(97736004)(50466002)(92566002)(2950100001)(5008740100001)(6806005)(54356999)(24736003)(76176999)(2501003)(19580395003)(106116001)(15975445007)(46406003)(50986999)(586003)(5250100002)(19580405001)(5004730100002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB030; H:plsapdm1.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB030; 2:v9qnofF9+tgz55JcdogV1X9V2Zsl3A2c5ANu7VLX83yVO1yb7xc9OH/m4bO//p3WUOmll/b51w3ip0KleZrIOKVZ1q7iJb06500f/qL2YzKtcnRpIFDLSNiZ27cmkcWE8uxspUFcTgUi4YcMmZNV2A==; 3:pM0N8yX4V/abIl1UkRfAbojAUZnE1hDZ0MZACiTY+kDGkRTTjNhuiUOVl/fZtY/QeVE4bUANqoxZJlXISPI//UeS5OC2GVCyebuhyi1FMkNwExdJfFk9/PXlM1ayLINVSguNO3YJCZAJk7YXMEUttmbZcmLSFiVR5xoXWTCZZRXdx0UO1wHIJLN+StjX429K1euWBUpEBtmKDHR4fz/5rLSasmfe7nJaCZbBJHsnMHhIQu516i0+hETnqdO35ohZZQ7pg0uGrFjkX0L5s58UOA==; 25:08ys3plgGliAYS+MJpmAeH+sDijOTYaCbo/vVbJ+CcGQ71X15fvJp9/gHzvXJ8qPrSTDcnogxk0905MfFB6ob5hWOeExmX9CojPCBjfRsAyLtDcim4SRPb5aMhUzSuYXnCeVgQk9j6/GV1Comgfpb/lga/WU9qfKpawvGtkBUKBiaOWmfpu6u61tMzo7u4KYMaQXWg6W4iCJt3jv1mS5eoxJiM1+mq3cOkRZv/RZ7FNxXLAEsM9kJnGJkh93vH1jjv476p2mQL/BWA2dVbx+GA==
X-Exchange-Antispam-Report-Test: UriScan:; BCL:0; PCL:0; RULEID:(8251501002);  SRVR:BL2FFO11HUB030; UriScan:(18430343700868)(97927398514766); 
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB030; 20:yrqweR+LXB1We2Lsarc1XZHPHT1VcusrsqzTZAepKZY9sjU7tPuIa+dbYR2HvpPDoUm2O1XtGLGLlh8fXxYinLD0gx1bSpGY+juRp5DTBWdpa0sFNHAh/WhfJDLlz9RVTpjkQOWs4MHiER5ujwnZc2/H7sD45teq36v3BmC2UBvQnRclO2HrOM4eKG4kKR5fizrHSE2TSkyfQktaZtNQGdCEcrswLX78wbZkkIhJO7SAwu6ecR5HWRXWi99BOIqe; 4:2rfPfZVBo3s+//KKUnQEbJKyUXmwet+VnHVCz+RLExYbp7yWO/AxH9CXLMsUHWLiwUv7ZswYXF4drYyj1+u238Xd70b76d4hSqI6bfnaJB33sPtK+5nSLIwti6Q+ZNxaCi4dQlS6ykslqnH8FS9zSmQ213Rm+G3Ray5/xSyiKJMqdIUzv20nohXQVZ0uWreRKP2OeYS6si6d9t7Uqxnk0EIHcSOSlgspYbNFkfelbDgJ/79vjM2nPon+GOE8AMIQzjZYm35A4EdL4zM3D1hog+VC5VnHnikeK2o9NOz/Iv1zc3fPfZWevB1iXj2tJ5DsvopO4YX5Jfzv35mY/xQfbO6vFcUSxdlaoPnf1GUgzns2XqHtmzL5QX/yEdtyPfHDNXmRGfGPTFyDVQwOlbDgycCuB6UqhnQKjjDf4OK18IP6mPJV/hBU+JNhMxv8C+zSjqCFQ4Zuj4f75TF2kLYbFw==
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:BL2FFO11HUB030; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB030; 
X-Forefront-PRVS: 0790FB1F33
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2FFO11HUB030; 23:ffCkmA26ihqecq/vEgXKQ+1CqhuAtWuxBZt6jlmQ?= =?us-ascii?Q?hAq9dC9401KxLHYcVmnYCNavLUqA8I/lQ34u3jFrSY76iLkFFbO53x8OZYsQ?= =?us-ascii?Q?1/XVBf8CP+sfBlktjjHatlgMsbDJwmwqry5UkSaMHvhq4RhZ7+u6s9WuPdVw?= =?us-ascii?Q?k96+pzFrQDciIl6bNvTX2oIGAsBotoA3zQsfVZdmV1ns6xJwqmshxzxvCtbH?= =?us-ascii?Q?wsLLJxSX7dUZ3tANm1qeeHn/mJ+DdRdCAMWxBA9/8rb77uLCVBHSdTy+xHsN?= =?us-ascii?Q?O48a9pepCATrFK1DTs+9NZNI9lDHGhyBlKBJzHMaxfHmpJINxd6ahaWDW70u?= =?us-ascii?Q?3NJ4eKOQxP5l6Pg4tYZELT3qGAUeoe1a4GlM/Wlf9W0vEdE4UPMbsQLiNxN2?= =?us-ascii?Q?wZKVseVXsDO7mr9oG+QjON+CYPzNqk8xrj7ExdB1xPd+h4tfvf7D+xUW16RW?= =?us-ascii?Q?tPz29HY8xmQrJQcK66+qPvHCYi8EYdVn7X/fIXh1GVmmxTcEzmuTED2pvNR5?= =?us-ascii?Q?+bj+a2wE4UU/Hr8ODBYOA/v5FTB/qjngRmLYgYORlstB/0NiC1467rVBnE/N?= =?us-ascii?Q?Bm4GSPa7zIW1xQoCmFjGRukZHVDVYvmrXixxoACkyO0e8ja1cnV6gerXKh6I?= =?us-ascii?Q?b7OBOT6Hj+uJ9+jfKJZv5Bhuebckc6Bo8tKcNBLdIZ7k9rrVf9H1LPkrtLmA?= =?us-ascii?Q?DMxAVPj50y5nfMPgwhG7F2X/EirJEhJHQDfd+7Vxdz4VRRv007gjatoGpenm?= =?us-ascii?Q?6y+bjKOT8FIU7E1QF1iYzQOcsefbYgFe/xtw5rK6f4lDZn7RcYyyDX6hyqkh?= =?us-ascii?Q?7Uq3EFwYaTjxrCJbuk9RL0MGY+0/TkcAzbaOBM520BfkP3tqYPMeNqSNngHM?= =?us-ascii?Q?TWGaly1wz+ozXQgbU9AtrRpum0iqBOd0ck6uR+OCIsZByFI3xG+sO4MkqevN?= =?us-ascii?Q?E4YkF4AKsseciayzmIMZJiMR3+MRXBi1Wm598tMIqTVhv67/d/qbkU4Xd3hJ?= =?us-ascii?Q?bkAek0pF1cTB//3JTvl5zXgq7zObfjTW+Nuro4b2UHp4j2s28X0CyKD8c66P?= =?us-ascii?Q?IxSBnEAV9S+Q3+eR80meiS9946IjGOqYkL3fcajQn8k/ThSpKqUBdcC/YVTT?= =?us-ascii?Q?LJ54q0hiTYwjd1GF2W6XoaTzcwbcc3hIRpUohVmXEoAzNH91eSK1vt6ommJQ?= =?us-ascii?Q?O/r/0bPIsJ4rtrae4q0K7YkYXx+T1UBbwcKJGi4n4xkjzGIn3qXnB6nOcsac?= =?us-ascii?Q?LXSK9bWrSJWW1IDeSxQsQfi7wrOQ9m0pIzllRGNZjBKSDws/rLbjiy1CR2de?= =?us-ascii?Q?ES3BTp3+64mm0pG9D7U6+TD6LK/X3+6xAUDT8hSXr3u4?=
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB030; 5:dLMz49Q8vmBWYezb9jg5wqBBXDoJlLud0SfC66YoD/oPPyGK3AvSSwOtpLEnWkJpS1i4r9L7GlOpDcg1bvUm2tcry/DvOPlmKkz5auL9lrThjXrsu1twhHGHMYMMBo2zkZyGe4vDMUCelzik54ixDg==; 24:kzHcPg4OFbRllWu6AbQLtNDa59L1GTQBJ5+/kraifC0KBgs0UKOPpFNKvdjDzQMjFfPfl0sfnnGEsVyvnHH+SOvIzQhIiVZ9qPndIV6chKE=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: sprint.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Dec 2015 21:17:32.2508 (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: BL2FFO11HUB030
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 14 Dec 2015 21:17:38 -0000

My point was numbering was delegated by the FCC to the states which are nec=
essarily constrained by geography and therefore so was number assignment an=
d therefore so was network architecture which routed based on the numbering=
.  (There are also services such as OS/DA and n11 which are geographically =
constrained by regulation and/or by needs.)

How to migrate (wrest?) authority for numbering from the states and place i=
t in a MODERN "solution" is an actual set of problems that could be documen=
ted for MODERN to solve that I wouldn't argue with.  Since the PSTN will no=
t evaporate, MODERN can only be successful as an evolution, not a green fie=
ld approach which supplants the existing numbering and routing processes an=
d infrastructure.

In North America real problems (requirements really) related to geographic =
number administration in the state PUCs that MODERN must address are area c=
ode relief, reclamation, and rate center consolidation approvals.

Pierce Gorman


-----Original Message-----
From: McGarry, Tom [mailto:Tom.McGarry@neustar.biz]
Sent: December 14, 2015 2:10 PM
To: Gorman, Pierce A [CTO] ; modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

You seem to be trying to make a different point - one about numbering autho=
rities.  The original point is about network architecture.

On 12/14/15 2:58 PM, "Gorman, Pierce A [CTO]" 
wrote:

>Replace "Numbering, interconnection and routing are highly dependent on
>geography: the PSTN was carefully designed to delegate switching
>intelligence geographically."
>
>With " Numbering, interconnection and routing are CURRENTLY highly
>dependent on geography:  the PSTN NUMBERING AUTHORITY was carefully
>designed to delegate NUMBERING AUTHORITY geographically.
>
>
>-----Original Message-----
>From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
>Sent: December 14, 2015 1:54 PM
>To: PFAUTZ, PENN L ; modern@ietf.org
>Subject: Re: [Modern] Problem statement draft as working group document
>
>WRT porting process:
>This doesn't address policy.  There is no way for a user to prove to a
>service provider that they do indeed have authority over the number.
>It suggests that there be a technical solution, a verifiable
>credential, that a user can submit to a service provider to prove they hav=
e authority.
>They have authority today, there's just no way to prove it.
>
>WRT interconnection:
>The point of that paragraph is that current numbering is highly
>dependent on geography, whereas in an IP environment it would be
>independent of geography.  In an IP environment it should be different.
>How about replacing the second sentence with:
>"Numbering, interconnection and routing are highly dependent on geography:
>the PSTN was carefully designed to delegate switching intelligence
>geographically."
>
>
>On 12/14/15 2:26 PM, "PFAUTZ, PENN L"  wrote:
>
>>All,
>>It's statements like
>>" Ideally the user would have full control of their TN and
>>   would drive the porting process on their own rather than rely on
>>   complex and time consuming back office processes among multiple
>>   service providers."
>>
>>that make a policy statement which concern me.
>>
>>As to Tom's question, it was the statement " Most TNs today are
>>assigned to specific geographies, at both an
>>   international level and within national numbering plans.  This has
>>   shaped the way that service providers interconnect"
>>
>>I think it was the reverse - numbering followed interconnection - and
>>the mechanisms I need for numbering will depend on the types of
>>interconnection I have to support.
>>
>>So, yes I do object to specifics in the document as opposed to the
>>enterprise as a whole.
>>
>>Penn Pfautz
>>AT&T Global Connection Management
>>
>>
>>-----Original Message-----
>>From: Adam Roach [mailto:adam@nostrum.com]
>>Sent: Monday, December 14, 2015 1:53 PM
>>To: Steve Donovan; modern@ietf.org
>>Subject: Re: [Modern] Problem statement draft as working group
>>document
>>
>>On 12/10/15 12:40, Steve Donovan wrote:
>>> There has been no response to this so I'm going to suggest we put a
>>> deadline on opinions.
>>>
>>> Please express your opinion on making
>>> draft-peterson-modern-problems-02 a working group document before
>>> Thursday, December 17th.
>>>
>>> It is important that anyone who supports the promotion of the
>>> document also express their opinion.
>>
>>I think this document is a good starting point for outlining the basic
>>shape of the problem and the use cases MODERN is intended to address.
>>
>>I'll note that on-list objections so far seem to be attempting to
>>re-litigate the formation of the working group rather than making
>>progress towards its milestones. As has been long established (at
>>least since the 2002 formation of XMPP), the decision to work on a
>>problem in the IETF is based on the following criteria: "is it
>>technically credible, are people willing to work on it, are people
>>willing to use it?" And, in particular: "we should be deciding things
>>based on the number of folks who want to do things, not the number oppose=
d."
>>
>>In terms of considering adoption of this specific document, I think we
>>need to be careful to parse out objections to its contents versus
>>objections to MODERN's very existence. So far, I have seen no on-list
>>objections that fall in the first category.
>>
>>/a
>>
>>
>>_______________________________________________
>>Modern mailing list
>>Modern@ietf.org
>>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail
>>m
>>an_
>>listinfo_modern&d=3DCwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufvee=
IDc
>>L
>>ext
>>Z1ooNcfp01IYIaVqsORjI&m=3Db8Du8PEdrEZo_LLqNvw5JrZtUM64muibjcmAAkrALxM&s=
=3D
>>E JyT AVbeKglij7G7DiYeWWywwrHAbKhJQYMH8snPpFg&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=3DCwIFAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI=
DcL
>ext
>Z1ooNcfp01IYIaVqsORjI&m=3DwX7NaCp4TR1we4d444AWJk4h5Znti2aqix5Cr5-fxCY&s=3D=
o
>l3y MdIchtzVnkdtU27FYlKIZ0SFMiXd-GbOP0BEn08&e=3D
>
>________________________________
>
>This e-mail may contain Sprint proprietary information intended for the
>sole use of the recipient(s). Any use by others is prohibited. If you
>are not the intended recipient, please contact the sender and delete
>all copies of the message.


________________________________

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


From nobody Mon Dec 14 16:11: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 5AE5F1A87DB for ; Mon, 14 Dec 2015 16:11:06 -0800 (PST)
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 ZF86b0KKkVnq for ; Mon, 14 Dec 2015 16:11:03 -0800 (PST)
Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 257C71A87D9 for ; Mon, 14 Dec 2015 16:11:03 -0800 (PST)
Received: (qmail 8453 invoked by uid 0); 15 Dec 2015 00:11:01 -0000
Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy4.mail.unifiedlayer.com with SMTP; 15 Dec 2015 00:11:01 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with  id tbqx1r0071MNPNq01br0Vc; Mon, 14 Dec 2015 16:51:01 -0700
X-Authority-Analysis: v=2.1 cv=IekUBwaa c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=fmwHIKxpFPMA:10 a=wUQvQvOEmiQA:10 a=jqBRFv0mrdUA:10 a=48vgC7mUAAAA:8 a=izV7ms69AAAA:8 a=hGBaWAWWAAAA:8 a=zQP7CpKOAAAA:8 a=Z80JlwQ0AAAA:8 a=RpNjiQI2AAAA:8 a=-rzDxdclRQCQnxffww8A:9 a=ZLd6shNFqrylHc3I:21 a=c8diN-EpqaCrg_JN:21 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us;  s=default;  h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=ZbmQHie3bNSSdcUmoNunskpdp/e/xYI6vgn4+IG8fXI=;  b=TOdfkgZwt4RIXcfRi6+vusCGIAlNpuddtFrRXbG/Hkks7nNkPGTR7ct7OaZ0oy6C8yIKWQwMVy8S+aa8l1RdFd1pkARy4UVd23yFX75Y9rVsvACVW5UTSU/a6i9FOlTT;
Received: from [70.42.157.30] (port=52958 helo=[10.14.104.159]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1a8ctM-0004Ew-Od; Mon, 14 Dec 2015 16:50:57 -0700
User-Agent: Microsoft-MacOutlook/0.0.0.151105
Date: Mon, 14 Dec 2015 18:50:45 -0500
From: Richard Shockey 
To: "Gorman, Pierce A [CTO]" , "McGarry, Tom" , "modern@ietf.org" 
Message-ID: <29317A20-8B9D-4BC9-A620-F59EE87367D2@shockey.us>
Thread-Topic: [Modern] Problem statement draft as working group document
References:   
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 70.42.157.30 authed with richard+shockey.us}
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 15 Dec 2015 00:11:06 -0000

On 12/14/15, 4:17 PM, "Modern on behalf of Gorman, Pierce A [CTO]"  wrote:

>My point was numbering was delegated by the FCC to the states which are ne=
cessarily constrained by geography and therefore so was number assignment an=
d therefore so was network architecture which routed based on the numbering.=
  (There are also services such as OS/DA and n11 which are geographically co=
nstrained by regulation and/or by needs.)
>
>How to migrate (wrest?) authority for numbering from the states and place =
it in a MODERN "solution" is an actual set of problems that could be documen=
ted for MODERN to solve that I wouldn't argue with.  Since the PSTN will not=
 evaporate, MODERN can only be successful as an evolution, not a green field=
 approach which supplants the existing numbering and routing processes and i=
nfrastructure.
>
>In North America real problems (requirements really) related to geographic=
 number administration in the state PUCs that MODERN must address are area c=
ode relief, reclamation, and rate center consolidation approvals.


RS> Which is the argument that the issues some want to address in the Probl=
em Statement here are not global but North American specific and properly sh=
ould be addressed in North American SDO=E2=80=99s that deal with these things. =20

Penn was right.  Sure there is an argument that we need a new way of lookin=
g at issues involving number allocation but frankly there is no stomach in t=
he North American industry for tackling those issues now or anytime in the i=
ntermediate future.  None of you can possibly imagine the cost involved in d=
ealing with telephone number administration. =20

Of all the things carriers have to deal with this is about number 164.  We =
need a better solution for interconnection data but again that problem set f=
or the time being is centered on North America.  Why does anyone want to try=
 to work on problems that have no possible chance of deployment in the reaso=
nable future.  This is not STIR.  The consensus on STIR is in fact global an=
d it it clear the progress of the work can have a real and demonstrable impa=
ct.




>
>Pierce Gorman
>
>
>-----Original Message-----
>From: McGarry, Tom [mailto:Tom.McGarry@neustar.biz]
>Sent: December 14, 2015 2:10 PM
>To: Gorman, Pierce A [CTO] ; modern@ietf.org
>Subject: Re: [Modern] Problem statement draft as working group document
>
>You seem to be trying to make a different point - one about numbering auth=
orities.  The original point is about network architecture.
>
>On 12/14/15 2:58 PM, "Gorman, Pierce A [CTO]" 
>wrote:
>
>>Replace "Numbering, interconnection and routing are highly dependent on
>>geography: the PSTN was carefully designed to delegate switching
>>intelligence geographically."
>>
>>With " Numbering, interconnection and routing are CURRENTLY highly
>>dependent on geography:  the PSTN NUMBERING AUTHORITY was carefully
>>designed to delegate NUMBERING AUTHORITY geographically.
>>
>>
>>-----Original Message-----
>>From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
>>Sent: December 14, 2015 1:54 PM
>>To: PFAUTZ, PENN L ; modern@ietf.org
>>Subject: Re: [Modern] Problem statement draft as working group document
>>
>>WRT porting process:
>>This doesn't address policy.  There is no way for a user to prove to a
>>service provider that they do indeed have authority over the number.
>>It suggests that there be a technical solution, a verifiable
>>credential, that a user can submit to a service provider to prove they ha=
ve authority.
>>They have authority today, there's just no way to prove it.
>>
>>WRT interconnection:
>>The point of that paragraph is that current numbering is highly
>>dependent on geography, whereas in an IP environment it would be
>>independent of geography.  In an IP environment it should be different.
>>How about replacing the second sentence with:
>>"Numbering, interconnection and routing are highly dependent on geography=
:
>>the PSTN was carefully designed to delegate switching intelligence
>>geographically."
>>
>>
>>On 12/14/15 2:26 PM, "PFAUTZ, PENN L"  wrote:
>>
>>>All,
>>>It's statements like
>>>" Ideally the user would have full control of their TN and
>>>   would drive the porting process on their own rather than rely on
>>>   complex and time consuming back office processes among multiple
>>>   service providers."
>>>
>>>that make a policy statement which concern me.
>>>
>>>As to Tom's question, it was the statement " Most TNs today are
>>>assigned to specific geographies, at both an
>>>   international level and within national numbering plans.  This has
>>>   shaped the way that service providers interconnect"
>>>
>>>I think it was the reverse - numbering followed interconnection - and
>>>the mechanisms I need for numbering will depend on the types of
>>>interconnection I have to support.
>>>
>>>So, yes I do object to specifics in the document as opposed to the
>>>enterprise as a whole.
>>>
>>>Penn Pfautz
>>>AT&T Global Connection Management
>>>
>>>
>>>-----Original Message-----
>>>From: Adam Roach [mailto:adam@nostrum.com]
>>>Sent: Monday, December 14, 2015 1:53 PM
>>>To: Steve Donovan; modern@ietf.org
>>>Subject: Re: [Modern] Problem statement draft as working group
>>>document
>>>
>>>On 12/10/15 12:40, Steve Donovan wrote:
>>>> There has been no response to this so I'm going to suggest we put a
>>>> deadline on opinions.
>>>>
>>>> Please express your opinion on making
>>>> draft-peterson-modern-problems-02 a working group document before
>>>> Thursday, December 17th.
>>>>
>>>> It is important that anyone who supports the promotion of the
>>>> document also express their opinion.
>>>
>>>I think this document is a good starting point for outlining the basic
>>>shape of the problem and the use cases MODERN is intended to address.
>>>
>>>I'll note that on-list objections so far seem to be attempting to
>>>re-litigate the formation of the working group rather than making
>>>progress towards its milestones. As has been long established (at
>>>least since the 2002 formation of XMPP), the decision to work on a
>>>problem in the IETF is based on the following criteria: "is it
>>>technically credible, are people willing to work on it, are people
>>>willing to use it?" And, in particular: "we should be deciding things
>>>based on the number of folks who want to do things, not the number oppos=
ed."
>>>
>>>In terms of considering adoption of this specific document, I think we
>>>need to be careful to parse out objections to its contents versus
>>>objections to MODERN's very existence. So far, I have seen no on-list
>>>objections that fall in the first category.
>>>
>>>/a
>>>
>>>
>>>_______________________________________________
>>>Modern mailing list
>>>Modern@ietf.org
>>>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail
>>>m
>>>an_
>>>listinfo_modern&d=3DCwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeIDc
>>>L
>>>ext
>>>Z1ooNcfp01IYIaVqsORjI&m=3Db8Du8PEdrEZo_LLqNvw5JrZtUM64muibjcmAAkrALxM&s=3D
>>>E JyT AVbeKglij7G7DiYeWWywwrHAbKhJQYMH8snPpFg&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=3DCwIFAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeIDcL
>>ext
>>Z1ooNcfp01IYIaVqsORjI&m=3DwX7NaCp4TR1we4d444AWJk4h5Znti2aqix5Cr5-fxCY&s=3Do
>>l3y MdIchtzVnkdtU27FYlKIZ0SFMiXd-GbOP0BEn08&e=3D
>>
>>________________________________
>>
>>This e-mail may contain Sprint proprietary information intended for the
>>sole use of the recipient(s). Any use by others is prohibited. If you
>>are not the intended recipient, please contact the sender and delete
>>all copies of the message.
>
>
>________________________________
>
>This e-mail may contain Sprint proprietary information intended for the so=
le use of the recipient(s). Any use by others is prohibited. If you are not =
the intended recipient, please contact the sender and delete all copies of t=
he message.
>
>_______________________________________________
>Modern mailing list
>Modern@ietf.org
>https://www.ietf.org/mailman/listinfo/modern


From nobody Mon Dec 14 16:22:53 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36021A882F for ; Mon, 14 Dec 2015 16:22:51 -0800 (PST)
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 CI9dSvgoumDZ for ; Mon, 14 Dec 2015 16:22:49 -0800 (PST)
Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 21E5E1A8734 for ; Mon, 14 Dec 2015 16:22:49 -0800 (PST)
Received: (qmail 17645 invoked by uid 0); 15 Dec 2015 00:22:48 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy4.mail.unifiedlayer.com with SMTP; 15 Dec 2015 00:22:48 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with  id tc2f1r00V1MNPNq01c2itt; Mon, 14 Dec 2015 17:02:47 -0700
X-Authority-Analysis: v=2.1 cv=dqRIVTQ4 c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=fmwHIKxpFPMA:10 a=wUQvQvOEmiQA:10 a=jqBRFv0mrdUA:10 a=48vgC7mUAAAA:8 a=Z80JlwQ0AAAA:8 a=HTNwYpP_MGw63AQH9qcA:9 a=gOm7ui7gLam2sLOi:21 a=s8uhF4YljHvBhrY-:21 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us;  s=default;  h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=FiZg/4+Up1Dz4cmzVn+rRo+FunFy6rYdKx5xG8XiHZ8=;  b=gaPey3I4UBleLKPXD8QZBq6SaOIDqNAOj+d+sGx7NwtlmLuOmUkyZzCaGKNVnRGPvV+E//c2qAgjSzFi3qXsNLr3o2J/mgsN2zMjFhkq3a45TVkTr/JEiS2UAszUlta4;
Received: from [70.42.157.30] (port=53080 helo=[10.14.104.159]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1a8d4i-0001yr-Fu; Mon, 14 Dec 2015 17:02:41 -0700
User-Agent: Microsoft-MacOutlook/0.0.0.151105
Date: Mon, 14 Dec 2015 19:02:27 -0500
From: Richard Shockey 
To: Adam Roach , Richard Hill , 'Steve Donovan' , 
Message-ID: <6C827E0C-682C-4484-8F21-20A446746858@shockey.us>
Thread-Topic: [Modern] Problem statement draft as working group document
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com> <056701d136a3$e1c49120$a54db360$@ch> <566F1A34.9020402@nostrum.com>
In-Reply-To: <566F1A34.9020402@nostrum.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 70.42.157.30 authed with richard+shockey.us}
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 15 Dec 2015 00:22:52 -0000

On 12/14/15, 2:36 PM, "Modern on behalf of Adam Roach"  wrote:

>On 12/14/15 13:16, Richard Hill wrote:
>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Adam Roach
>>
>>> I think this document is a good starting point for outlining the basic
>>> shape of the problem and the use cases MODERN is intended to address.
>> Yes, but it seems to me to be placing the cart before the horse. The dra=
ft
>> is outlining technical solutions for things that aren't, as far as I kno=
w,
>> yet possible from a regulatory point of view.
>
>Where you see a cart and a horse, I see a chicken and an egg. Someone=20
>has to go first. If taken in the opposite order, your objection could=20
>easily be reversed to read "the proposed regulations are outlining=20
>requirements for solutions that aren't, as far as I know, yet=20
>technically possible."
>
>In any case, what we say on the topic in *this* forum is largely=20
>academic, since it's not the WG participants or even the chairs that=20
>decide to start and end WGs. If you'd like to debate the existence of=20
>MODERN -- which seems to be your implied intent -- that's a broader=20
>conversation that you need to take up with the ADs and the IESG.


RS> Adam our objections were NOT considered during the charter phase here. =
 This was the worst chartering process I=E2=80=99ve ever witnessed in the IETF. An=
d I personally blame the IESG here for ignoring our concerns. And the sponso=
ring AD in particular..the record on that is clear.=20


> I'll=20
>note that the question of existence has already been asked and answered=20
>based on earlier discussions, so you'll need to show up with previously=20
>unmade arguments.
>
>But that conversation doesn't have bearing on whether this document is a=20
>good match for the WG charter.


RS> The conversation is this a proper WG item .. We say NO.=20


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


From nobody Mon Dec 14 16:33:01 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC9A1A892F for ; Mon, 14 Dec 2015 16:33:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.001
X-Spam-Level: 
X-Spam-Status: No, score=-4.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, 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 xteTc5ffsCGI for ; Mon, 14 Dec 2015 16:32:58 -0800 (PST)
Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 10D421A88ED for ; Mon, 14 Dec 2015 16:32:55 -0800 (PST)
Received: (qmail 26721 invoked by uid 0); 15 Dec 2015 00:32:54 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy4.mail.unifiedlayer.com with SMTP; 15 Dec 2015 00:32:54 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with  id tcCp1r0041MNPNq01cCssM; Mon, 14 Dec 2015 17:12:53 -0700
X-Authority-Analysis: v=2.1 cv=dqRIVTQ4 c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=fmwHIKxpFPMA:10 a=wUQvQvOEmiQA:10 a=jqBRFv0mrdUA:10 a=48vgC7mUAAAA:8 a=izV7ms69AAAA:8 a=zQP7CpKOAAAA:8 a=Z80JlwQ0AAAA:8 a=RpNjiQI2AAAA:8 a=QyvrBePqzwdjPBpckmsA:9 a=R80ljZ3Rrk86eTis:21 a=7QQJKoJnalv6JQkv:21 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us;  s=default;  h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=ejUxMr4EQ5ycn/3Rf6b17lnksF/ECvwp1ZM9Sn8CboM=;  b=N4VJS8BD3apSXfQD2uzf4VWu9IpAcqPrfNf5GvU/gvtq5VxP03c3Lk/dcFKho/IGbrK3Ezu6zENgy7KyyCnSdQxYH85sojOA8Wgx5OW8HPXNgaWDncVl7znL5eCqHWTy;
Received: from [70.42.157.30] (port=30572 helo=[10.14.104.159]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1a8dEP-0007XS-Fp; Mon, 14 Dec 2015 17:12:50 -0700
User-Agent: Microsoft-MacOutlook/0.0.0.151105
Date: Mon, 14 Dec 2015 19:12:23 -0500
From: Richard Shockey 
To: "Gorman, Pierce A [CTO]" , "McGarry, Tom" , "PFAUTZ, PENN L" , "modern@ietf.org" 
Message-ID: <0102BBFE-C7A0-4347-851B-B90690D27379@shockey.us>
Thread-Topic: [Modern] Problem statement draft as working group document
References: <38726EDA2109264987B45E29E758C4D605925616@MISOUT7MSGUSRDD.ITServices.sbc.com>  
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 70.42.157.30 authed with richard+shockey.us}
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 15 Dec 2015 00:33:00 -0000

WELL Pierce for the time being North American Numbering is actually dependent on geography.  However having sat through X hours or more of the last NANC meeting,  a workshop for NARUC in Austin and having read the letters from Congress, the industry and the Wireline Competition bureau.  The day may actually come that we can actually have National Geographic Number Portability NG/NP and national 10 digit dialing .. Of course I will probably be dead before its fully implemented but that is a side issue. 

Again a North Americian specific issue. 




On 12/14/15, 2:58 PM, "Modern on behalf of Gorman, Pierce A [CTO]"  wrote:

>Replace "Numbering, interconnection and routing are highly dependent on geography: the PSTN was carefully designed to delegate switching intelligence geographically."
>
>With " Numbering, interconnection and routing are CURRENTLY highly dependent on geography:  the PSTN NUMBERING AUTHORITY was carefully designed to delegate NUMBERING AUTHORITY geographically.
>
>
>-----Original Message-----
>From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
>Sent: December 14, 2015 1:54 PM
>To: PFAUTZ, PENN L ; modern@ietf.org
>Subject: Re: [Modern] Problem statement draft as working group document
>
>WRT porting process:
>This doesn't address policy.  There is no way for a user to prove to a service provider that they do indeed have authority over the number.  It suggests that there be a technical solution, a verifiable credential, that a user can submit to a service provider to prove they have authority.
>They have authority today, there's just no way to prove it.
>
>WRT interconnection:
>The point of that paragraph is that current numbering is highly dependent on geography, whereas in an IP environment it would be independent of geography.  In an IP environment it should be different.  How about replacing the second sentence with:
>"Numbering, interconnection and routing are highly dependent on geography:
>the PSTN was carefully designed to delegate switching intelligence
>geographically."
>
>
>On 12/14/15 2:26 PM, "PFAUTZ, PENN L"  wrote:
>
>>All,
>>It's statements like
>>" Ideally the user would have full control of their TN and
>>   would drive the porting process on their own rather than rely on
>>   complex and time consuming back office processes among multiple
>>   service providers."
>>
>>that make a policy statement which concern me.
>>
>>As to Tom's question, it was the statement " Most TNs today are
>>assigned to specific geographies, at both an
>>   international level and within national numbering plans.  This has
>>   shaped the way that service providers interconnect"
>>
>>I think it was the reverse - numbering followed interconnection - and
>>the mechanisms I need for numbering will depend on the types of
>>interconnection I have to support.
>>
>>So, yes I do object to specifics in the document as opposed to the
>>enterprise as a whole.
>>
>>Penn Pfautz
>>AT&T Global Connection Management
>>
>>
>>-----Original Message-----
>>From: Adam Roach [mailto:adam@nostrum.com]
>>Sent: Monday, December 14, 2015 1:53 PM
>>To: Steve Donovan; modern@ietf.org
>>Subject: Re: [Modern] Problem statement draft as working group document
>>
>>On 12/10/15 12:40, Steve Donovan wrote:
>>> There has been no response to this so I'm going to suggest we put a
>>> deadline on opinions.
>>>
>>> Please express your opinion on making
>>> draft-peterson-modern-problems-02 a working group document before
>>> Thursday, December 17th.
>>>
>>> It is important that anyone who supports the promotion of the
>>> document also express their opinion.
>>
>>I think this document is a good starting point for outlining the basic
>>shape of the problem and the use cases MODERN is intended to address.
>>
>>I'll note that on-list objections so far seem to be attempting to
>>re-litigate the formation of the working group rather than making
>>progress towards its milestones. As has been long established (at least
>>since the 2002 formation of XMPP), the decision to work on a problem in
>>the IETF is based on the following criteria: "is it technically
>>credible, are people willing to work on it, are people willing to use
>>it?" And, in particular: "we should be deciding things based on the
>>number of folks who want to do things, not the number opposed."
>>
>>In terms of considering adoption of this specific document, I think we
>>need to be careful to parse out objections to its contents versus
>>objections to MODERN's very existence. So far, I have seen no on-list
>>objections that fall in the first category.
>>
>>/a
>>
>>
>>_______________________________________________
>>Modern mailing list
>>Modern@ietf.org
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailm
>>an_
>>listinfo_modern&d=CwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcL
>>ext
>>Z1ooNcfp01IYIaVqsORjI&m=b8Du8PEdrEZo_LLqNvw5JrZtUM64muibjcmAAkrALxM&s=E
>>JyT AVbeKglij7G7DiYeWWywwrHAbKhJQYMH8snPpFg&e=
>
>_______________________________________________
>Modern mailing list
>Modern@ietf.org
>https://www.ietf.org/mailman/listinfo/modern
>
>________________________________
>
>This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
>
>_______________________________________________
>Modern mailing list
>Modern@ietf.org
>https://www.ietf.org/mailman/listinfo/modern


From nobody Mon Dec 14 22:31:47 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2021B2B6C for ; Mon, 14 Dec 2015 22:31:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCGSebvGhPvk for ; Mon, 14 Dec 2015 22:31:43 -0800 (PST)
Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91F3C1B2B6A for ; Mon, 14 Dec 2015 22:31:43 -0800 (PST)
Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBF6Vc2s016372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 15 Dec 2015 07:31:39 +0100
Received: from RHillNew (adsl-178-39-158-20.adslplus.ch [178.39.158.20]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBF6VbL8008994; Tue, 15 Dec 2015 07:31:38 +0100
From: "Richard Hill" 
To: "'Dwight, Timothy M \(Tim\)'" , "'McGarry, Tom'" , "'Gorman, Pierce A [CTO]'" , 
References:   <2B0F677F0B95454297753F58D4A07FA30282E7193A@FHDP1LUMXC7V31.us.one.verizon.com>
In-Reply-To: <2B0F677F0B95454297753F58D4A07FA30282E7193A@FHDP1LUMXC7V31.us.one.verizon.com>
Date: Tue, 15 Dec 2015 07:31:37 +0100
Message-ID: <007601d13702$40a989d0$c1fc9d70$@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: AQHRHl26DyraNZUDF0WIF1b3d5Qwlp7FC3CAgAZM7ICAAAlogP//s+EAgABVEwD//69hAIAAAnfggACpdlA=
Content-Language: en-us
X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8
X-Antivirus-Code: 0x100000
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 15 Dec 2015 06:31:46 -0000

Please see embedded comments below.

Thanks and best,
Richard

> -----Original Message-----
> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Dwight,
> Timothy M (Tim)
> Sent: Monday, December 14, 2015 21:46
> To: McGarry, Tom; Gorman, Pierce A [CTO]; modern@ietf.org
> Subject: Re: [Modern] Problem statement draft as working group document
> 
> Tom,
> 
> What I think you're saying is that the function of a telephone number
> in an "all IP world" is expected to be different than in the PSTN.
> 
> Telephone numbers are used for routing in the PSTN,

That was true back in the old days of rotary dialing, but it is to a large
extent no longer the case at the national level with SS7. Many countries
have full fixed number portability, so the E.164 number no longer has any
geographical significance.

> which is the
> fundamental reason their assignment generally reflects the topology of
> the network.   The PSTN routes on number prefixes, as does the
> Internet.  There are differences in the details, but the fundamental
> need for address summarization is common.  This results in address
> assignments that reflect network topology.

Actually in today's telephone network, the E.164 number is a name, analogous
to Internet domain names.  The telephony equivalent of an IP address is the
IMSI (E.212) for mobile and ISPC/SANC (Q.709) for fixed.

The situation that you describe may be valid for some countries, but not
others.

> 
> I *think* the reason for the assumption that telephone number
> assignment in an all-IP world need not reflect geography is that it's
> assumed that telephone numbers in that environment are no longer
> treated as addresses.   Instead they are generally expected to be
> identifiers, mapped to network addresses through some sort of
> translation process.  Right?

Yes, see above. And it is not just in an all-IP environment. As I said
above, this has been the case for some years in some countries, even in a
non-all-IP-world.

SNIP



From nobody Tue Dec 15 07:53:46 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4A31A905B for ; Tue, 15 Dec 2015 07:53:45 -0800 (PST)
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 fjg9wpMZBJz1 for ; Tue, 15 Dec 2015 07:53:44 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2FD41A9026 for ; Tue, 15 Dec 2015 07:53:11 -0800 (PST)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tBFFr5C8051232 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 15 Dec 2015 09:53:06 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
To: Richard Shockey , Richard Hill , "'Steve Donovan'" , modern@ietf.org
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com> <056701d136a3$e1c49120$a54db360$@ch> <566F1A34.9020402@nostrum.com> <6C827E0C-682C-4484-8F21-20A446746858@shockey.us>
From: Adam Roach 
Message-ID: <56703761.9010409@nostrum.com>
Date: Tue, 15 Dec 2015 09:53:05 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <6C827E0C-682C-4484-8F21-20A446746858@shockey.us>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 15 Dec 2015 15:53:45 -0000

On 12/14/15 18:02, Richard Shockey wrote:
>
> On 12/14/15, 2:36 PM, "Modern on behalf of Adam Roach"  wrote:
>
> In any case, what we say on the topic in *this* forum is largely
> academic, since it's not the WG participants or even the chairs that
> decide to start and end WGs. If you'd like to debate the existence of
> MODERN -- which seems to be your implied intent -- that's a broader
> conversation that you need to take up with the ADs and the IESG.
>
> RS> Adam our objections were NOT considered during the charter phase here.  This was the worst chartering process I’ve ever witnessed in the IETF. And I personally blame the IESG here for ignoring our concerns. And the sponsoring AD in particular..the record on that is clear.

If you earnestly believe this, there is a process for dealing with your 
concerns. Disrupting efforts to get work done on the working group 
mailing list is not part of that process. If you honestly don't know how 
to proceed, please contact me directly, and I'll give you pointers. I 
think you have my cell phone number -- feel free to use it.

>> I'll
>> note that the question of existence has already been asked and answered
>> based on earlier discussions, so you'll need to show up with previously
>> unmade arguments.
>>
>> But that conversation doesn't have bearing on whether this document is a
>> good match for the WG charter.
>
> RS> The conversation is this a proper WG item .. We say NO.
>

The conversation on this list is: given the charter of MODERN, and given 
a milestone of "Submit Architecture Overview Draft to IESG," is this 
document a reasonable starting point?

If your answer is "no," *and* there is some document for which you would 
say "yes," then the useful thing to do here is outline what such a 
document would say.

If there is no document for which your answer is "yes," then your 
objection is to the givens, not the question. If that's the case, your 
objections amount to an attempt to disrupt the consensus process through 
a "denial-of-service"-style attack.

In the former case, I implore you to usefully describe what the document 
should say. In the latter, I request -- both as a personal favor and as 
a professional courtesy -- that you please work within accepted IETF 
process to have your grievance heard rather than disrupting the mailing 
list discussion.

/a


From nobody Tue Dec 15 09:05:36 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D8D1A8A59 for ; Tue, 15 Dec 2015 09:05:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfhEHdP6siJo for ; Tue, 15 Dec 2015 09:05:32 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0111.outbound.protection.outlook.com [65.55.169.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA0AF1A8900 for ; Tue, 15 Dec 2015 09:05:31 -0800 (PST)
Received: from BL2FFO11OLC013.protection.gbl (10.173.160.32) by BL2FFO11HUB026.protection.gbl (10.173.161.50) with Microsoft SMTP Server (TLS) id 15.1.346.13; Tue, 15 Dec 2015 17:05:29 +0000
Authentication-Results: spf=pass (sender IP is 144.230.32.81) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com;
Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.32.81 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.81; helo=preapdm2.corp.sprint.com;
Received: from preapdm2.corp.sprint.com (144.230.32.81) by BL2FFO11OLC013.mail.protection.outlook.com (10.173.160.161) with Microsoft SMTP Server (TLS) id 15.1.346.13 via Frontend Transport; Tue, 15 Dec 2015 17:05:29 +0000
Received: from pps.filterd (preapdm2.corp.sprint.com [127.0.0.1]) by preapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id tBFF3ueu034969;  Tue, 15 Dec 2015 12:05:29 -0500
Received: from plswe13m08.ad.sprint.com (plswe13m08.corp.sprint.com [144.229.214.27]) by preapdm2.corp.sprint.com with ESMTP id 1yrdfug8jp-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 15 Dec 2015 12:05:29 -0500
Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 15 Dec 2015 11:05:28 -0600
Received: from PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed]) by PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed%24]) with mapi id 15.00.1076.000; Tue, 15 Dec 2015 11:05:28 -0600
From: "Gorman, Pierce A [CTO]" 
To: Richard Hill , "'Dwight, Timothy M (Tim)'" , "'McGarry, Tom'" , "modern@ietf.org" 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHRHl26KCigIa6jakmAIZNM6lCGV57FC3CAgAZM7ICAAAlogP//s+EAgABVEwD//69hAIAAAnfggACpdlCAAKdXgA==
Date: Tue, 15 Dec 2015 17:05:27 +0000
Message-ID: 
References:   <2B0F677F0B95454297753F58D4A07FA30282E7193A@FHDP1LUMXC7V31.us.one.verizon.com> <007601d13702$40a989d0$c1fc9d70$@ch>
In-Reply-To: <007601d13702$40a989d0$c1fc9d70$@ch>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.214.116.44]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC013; 1:OH9jjlkF80o8rIeoNXWjSC41absS+UlYvgXAuscl3+nmyvDGbKyRx/SMvE4V46L0A+2Z06lrLL2LRkiys/enyChQlmYC0EKAI9wlTPNicsjM5kf0p8khhMl021gf1cOEWyixmL6gRPGYIfudx5YYOT5uKTuic0vHVlFGloRAS1n7RdIZrnUdoBmyVLh/jziR6j7Iw6NIHeOQvscZRwdbHTN4uYyIjzBgxiHg0LZYzELiark7Tz5PjYcAMSx9D+pAwotcbVZ16dOiF8KX986ifFA/S6N33V7e90Haftqc3+bCTAtFFqCYDr5/zYt9LySzxR3uU/xDyGPpFzd4sTfFXvyHcnnmHTc4eM6BZ89p/YUJoGvzaNlv7MB49XbZTVltCMrI49D9oQE/Uz+bz2Ea0g==
X-Forefront-Antispam-Report: CIP:144.230.32.81; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(13464003)(199003)(189002)(377454003)(5008740100001)(50466002)(2900100001)(92566002)(97736004)(106116001)(2950100001)(6806005)(50986999)(54356999)(5004730100002)(46406003)(15975445007)(586003)(5250100002)(19580395003)(19580405001)(2501003)(76176999)(24736003)(5001770100001)(81156007)(97756001)(107886002)(5001960100002)(106466001)(23726003)(33646002)(5003600100002)(87936001)(11100500001)(189998001)(1220700001)(47776003)(86362001)(108616004)(6116002)(3846002)(102836003)(93886004)(1096002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB026; H:preapdm2.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB026; 2:01MJBHAxa8EL6X5i6TWBx18gxPvaNlIwp/qctTUg85etCn0d7r+oV0rBXKCtv4ZMc/GCyrR4Bj85QQfHRuXt9vSnAENh9jF7+RiNIcG8KATigt84ozABo+2gPiF/5egkDpcCkNEVa4Q5vgIPUCTpcw==; 3:M7++Bpyki0tjVs7Yt5ATz0x7hAoh9r0VdoLTujIAmBZ2XujDr2UJ4G3lsmnbXm7mJloHxzlN4OVD6UF9KJBYLX8yd5DC2Ct4snt8fiSX4jYQ7/47g4ad9/jPym5sIQQuA+yTYOrcFHFBOcuE3JVFyUBzvErVUY9C+xFh3bQe/oVMQe+K98MnbVai3TavqG34q71Ctii/2ZhMqZZrzza1PRGw+TgYo+vFq2Luw7OPMtvnaiJtJMJJ89l9u92wYLiGo3got4CNJSHuRC5L7whL7g==; 25:h0eDKwu2yk0PPDM0MLKgFbmO9hrxpnJj6+k7H4hqxyfHXYi0vQs1KWsxLyaJmaxdKlQ5xlUR6+4Digs5qvtN4REuLc61mNvmsFDbMeLE4dqnW1ME+015lg/AS2A9hlNbH3KzMZ+EOrcAloYB2NF7JMKhm3NwHlgPxj3cNsj8cmz5owjoxYaJDtIScKpR/7TZmJpiCjJLMALar0BDL14qHVIKsavkfvxal//VNxOTWrU4e5B5ZjtRk9DwSop7pYIbNETk3GFYy9Isi/FyddskIg==
X-Exchange-Antispam-Report-Test: UriScan:; BCL:0; PCL:0; RULEID:(8251501002);  SRVR:BL2FFO11HUB026; UriScan:(18430343700868);
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB026; 20:hg/FiSXElxPjVqF5aZHupJmOOypQ0JEj5wiCiWOfjPippKLvE3xPBz01aTTbHNx+lq8vq4rQ+xYjh7ChCeUfLatFdv+Dg//lE1balJKjd2Mggw4+N2kDc3SNiOC7C6PENp6Yx7OB5iEGgzFURKR1DzTLvLFUiHVTMecpDYPYZVifQcAj9F7bCoDbG0XmrTnBIp+BdZqkW18eOnnuN1KTANmWcR5ocfG5PdQElnBFfVz6U8mX2/F06VkM7TTkyEgD; 4:b6foBt5xVuuoxyxLHIIC3zbcoCZsef0vHKguq8Kb7cogS8gGzroauJjO+D8DcDXSPWItjkHtlk6THsSmD+J3oI8MJgQMyDGgO05V0RDeAhvMhf10URauMdG14FnDivAXk8A6PmxGRg8xJcMO1DVBzOmzLMpatbfBEO26CXCPC23ot3Et9ld51jAmyAEGSdO4b/15t09pjeo1L9S1ojnAiz6VwC7fxgoVZnU+Kp7E7kBtB/JG9CivI4vBccW9oiYy67jETVejppT61MatRJvycWlfdyylXrk4dGVwSy1zitt5EbHr2eKL7we6GW78AUVR8CaCRxcTfo6lOqMBWj28JafPg3mOqluS7TmjlyzftvURcb2CSMEyLv+ne/j5LFBwsB3k0Qj9jN213FH8Rm3OI8rTjJNH+YzuDdCMAtY3Y/Q4uCI7jFSXXbjctTHOyZ0x
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001); SRVR:BL2FFO11HUB026; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB026; 
X-Forefront-PRVS: 07915F544A
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2FFO11HUB026; 23:pi5Ok7Gk7YzwCYE1Iw1QmjHd6HbZAtoNEc2/kANH?= =?us-ascii?Q?2HqDDBNizngWxSE7qHjcVMwHCZifqGI8tNn+WSk5tlE2EHZFkFOTyQHEgGyu?= =?us-ascii?Q?7ndWfp0KWs7+TcD4eJHfV0cxpOd9vj7IyM7Me5w2lofW+g7KZAZUprm2uumv?= =?us-ascii?Q?3kXQPQvEA8yoWtA/uOk9NJ3XE6Yn9iNFu04XwVwNWs9wbQbZ2q7k1yKVS47v?= =?us-ascii?Q?sfpM1nb+NA8zNkyFC/zRcqVxSq6fq5CIMOOyhHoYhNQKxEJlNu3GpXgMsGqx?= =?us-ascii?Q?d1+jdj5CNUluFX7nsSJCQqhwEgcDtdwNi4mL4fqAKtEcvwvM6Sr6ZCA3CnpG?= =?us-ascii?Q?CH6IPSvszGWe3s32tISxJFh8LZLAX5mS/b3Z8scUKbbNnbthwIvqxUb5HrUg?= =?us-ascii?Q?Ucz2RIpKgA25P+tfoHTdrMlseYC3n31AbVO7PvI/myaamh/bRP0kj3zJjCTQ?= =?us-ascii?Q?7XodpCcpSWlBAhu211sgfirwox0FwKBcU2koJVdwsauJO56n4jhpM3fKA1YG?= =?us-ascii?Q?3Mbt5OnpLf27q9HYJFsqHVXF5rCTOVxxsCpvKvZILA+f35aaJFkN4TIc+rDs?= =?us-ascii?Q?9QNQ3/CNW7ux4h4N7fuMgY6Ga5HXHb8aLsaV4Pb/o4x8JqSZHYPKwELBnSsP?= =?us-ascii?Q?JMxJMZs4jkueK+Cln61HKcDwtlK1WFl4MhH9W8xzG9/fUkRXKywF0GNbiLQk?= =?us-ascii?Q?6vUMHRD/jRdz58uUT+pJ37lMb9kSTua7dGxD3Y48i5O8uiD7VW304zstpx79?= =?us-ascii?Q?alrYRZeC+6/dK+uZqeeijttjJQMDuTw+K6A17/tXySMXaK3INQE8H1OZotsq?= =?us-ascii?Q?CPTqZbcNC9aPlngDi1lyD7L+/7f/+1uZ+8TYNBlwzFx8yCCLE/3cKigmUtr7?= =?us-ascii?Q?tDjqrjE1Jm3QkiZAySrbFe1T9T6BfiR+QBgzXclsnU6TefTSUOWoIfMo2TKb?= =?us-ascii?Q?1bSW4kEuawO4r5mk0bTX9IYwY5iHRo9Zh/U7TKOtWjWccIHQmTH0v6PsPTfe?= =?us-ascii?Q?E8RLTe82AReTMJz8RtdDBo6mgobK0P6qI+zwWtyr6qOBAVC6koVbzltC+1NF?= =?us-ascii?Q?UR8CnfkjNCJ3D8XW1A4hWtm02acpvyrJPcm49AhCTmkvCfPpa3CYqg7zHjCC?= =?us-ascii?Q?9CpqgJptHptfb5r+vyemU5vwFKNjO3WvDXtywkuHROLM9hjrVBee21+9S5u/?= =?us-ascii?Q?QJ4JolfRsgEbB968b2Jh2FW8Sw7U8LauPxqiiFLivs9i/dRyEIcUJwzxbVVz?= =?us-ascii?Q?rSXyHC/x8E6KNr9OopFELo61x0sUCPgU17InIPwK?=
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB026; 5:tbf1xgl52UwQp2mhN1x6Bfxn3wszqYZWu2Vmoqbnsb23fgWLP5+LrknMcIc3b4CH+wfvKMZrCvB/WFqJBf4c7CK8c1vZrHzglelH2IOs5jJIooPJqa2oIO4PKZdJM2KsKW5yEs/X89EwdGDiVr03Gg==; 24:tiKFhOpAQqrS8wQj47DpiKwmVTrIxKnX9JcI3iPJZJq16a2W0KMU4b5ZpgIc5ZD3naoGvQxU40HBL4tmXsPKhOFG6YnRGscyIzl4kosMKNI=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: sprint.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Dec 2015 17:05:29.7215 (UTC)
X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.81];  Helo=[preapdm2.corp.sprint.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2FFO11HUB026
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 15 Dec 2015 17:05:35 -0000

Comments in-line.

Pierce

-----Original Message-----
From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard Hill
Sent: December 15, 2015 12:32 AM
To: 'Dwight, Timothy M (Tim)' ; 'McGarry, Tom' =
; Gorman, Pierce A [CTO] ; modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

Please see embedded comments below.

Thanks and best,
Richard

> -----Original Message-----
> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Dwight,
> Timothy M (Tim)
> Sent: Monday, December 14, 2015 21:46
> To: McGarry, Tom; Gorman, Pierce A [CTO]; modern@ietf.org
> Subject: Re: [Modern] Problem statement draft as working group
> document
>
> Tom,
>
> What I think you're saying is that the function of a telephone number
> in an "all IP world" is expected to be different than in the PSTN.
>
> Telephone numbers are used for routing in the PSTN,

That was true back in the old days of rotary dialing, but it is to a large =
extent no longer the case at the national level with SS7. Many countries ha=
ve full fixed number portability, so the E.164 number no longer has any geo=
graphical significance.

PG-> SS7 is irrelevant to the number assignment question/issue.  I'll agree=
 Non-geographic portability (NGP) will soon be required per regulation and =
supported.  NGP does not inherently remove the geographical-ness of previou=
sly assigned numbers, or their state PUC regulated assignment process (for =
the NANP at least).  i.e., all new numbers assigned would still have a geog=
raphic relationship by default per the existing regulatory and commercial p=
rocesses.  Over time NGP will erode the strongly-typed relationship between=
 assigned numbers and geography up to the point of balance between newly as=
signed numbers and the nomadic nature of the new number during their user's=
' lifetimes.  Regardless, what is it about NGP and eroding the relationship=
 between numbers and their geography that is a problem for MODERN to addres=
s?

> which is the
> fundamental reason their assignment generally reflects the topology of
> the network.   The PSTN routes on number prefixes, as does the
> Internet.  There are differences in the details, but the fundamental
> need for address summarization is common.  This results in address
> assignments that reflect network topology.

Actually in today's telephone network, the E.164 number is a name, analogou=
s to Internet domain names.  The telephony equivalent of an IP address is t=
he IMSI (E.212) for mobile and ISPC/SANC (Q.709) for fixed.

PG-> I would use the example of portability as an example exactly opposite =
to your assertion that E.164 numbers are analagous to Internet domain names=
 which are clearly not portable (as I was reminded by my ISP e-mail service=
 recently).  In fact, if MODERN were to propose a mechanism to address the =
lack of domain name portability, I would be heartily in favor of that.  Per=
haps we can force e-mail addresses to be reachable only via a resolution to=
 phone numbers?

The situation that you describe may be valid for some countries, but not ot=
hers.

>
> I *think* the reason for the assumption that telephone number
> assignment in an all-IP world need not reflect geography is that it's
> assumed that telephone numbers in that environment are no longer
> treated as addresses.   Instead they are generally expected to be
> identifiers, mapped to network addresses through some sort of
> translation process.  Right?

Yes, see above. And it is not just in an all-IP environment. As I said abov=
e, this has been the case for some years in some countries, even in a non-a=
ll-IP-world.

SNIP


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

________________________________

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


From nobody Tue Dec 15 09:18: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 0F21E1A906A for ; Tue, 15 Dec 2015 09:18:31 -0800 (PST)
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 6-fT9mIaMk4j for ; Tue, 15 Dec 2015 09:18:28 -0800 (PST)
Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF5E01A90D9 for ; Tue, 15 Dec 2015 09:18:27 -0800 (PST)
Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.15.0.59/8.15.0.59) with SMTP id tBFHH7Il007377; Tue, 15 Dec 2015 12:18:22 -0500
Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 1yrqn7p5s1-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Dec 2015 12:18:22 -0500
Received: from STNTEXMB11.cis.neustar.com ([169.254.1.102]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Tue, 15 Dec 2015 12:18:21 -0500
From: "McGarry, Tom" 
To: "Dwight, Timothy M (Tim)" , "modern@ietf.org" 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHRHl26DyraNZUDF0WIF1b3d5Qwlp7FC3CAgAZM7ICAAAlogP//s+EAgABVEwD//69hAIAAAnfggAFf4YA=
Date: Tue, 15 Dec 2015 17:18:21 +0000
Message-ID: 
In-Reply-To: <2B0F677F0B95454297753F58D4A07FA30282E7193A@FHDP1LUMXC7V31.us.one.verizon.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.2.130206
x-originating-ip: [10.33.205.125]
Content-Type: multipart/mixed; boundary="_002_D295B33632EB8tommcgarryneustarbiz_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-12-15_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310007 definitions=main-1512150275
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 15 Dec 2015 17:18:31 -0000

--_002_D295B33632EB8tommcgarryneustarbiz_
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1FD6639404BE1049A881010B1CB8E9FA@neustar.biz>
Content-Transfer-Encoding: quoted-printable

Yes, on IP networks TNs are identifiers and not addresses (as they are on
TDM networks).=20

I also agree that there can still be a linkage between TNs and geography
in an all-IP environment.  The draft does not say that there will be no
linkage whatsoever.

On 12/14/15 3:46 PM, "Dwight, Timothy M (Tim)"
 wrote:

>Tom,
>
>What I think you're saying is that the function of a telephone number in
>an "all IP world" is expected to be different than in the PSTN.
>
>Telephone numbers are used for routing in the PSTN, which is the
>fundamental reason their assignment generally reflects the topology of
>the network.   The PSTN routes on number prefixes, as does the Internet.
>There are differences in the details, but the fundamental need for
>address summarization is common.  This results in address assignments
>that reflect network topology.
>
>I *think* the reason for the assumption that telephone number assignment
>in an all-IP world need not reflect geography is that it's assumed that
>telephone numbers in that environment are no longer treated as addresses.
>  Instead they are generally expected to be identifiers, mapped to
>network addresses through some sort of translation process.  Right?
>
>If so I would buy that the rationale for embedding geography into
>telephone numbers, in an "all IP world", is different than it has been in
>the PSTN.  I don't think it's gone though.  As a simple example, we will
>probably need to maintain the notion of a "country code", because
>telephone numbers are national resources and subject to national laws and
>regulation.  It might also be that within a country, number assignment is
>performed by agencies responsible for certain geographic areas.  It seems
>technically possible that they all share a single pool of numbers, but
>some countries might elect not to.  They might prefer instead to
>partition the address space.  Such partitioning would be reflected in the
>addresses they assign.   So I think it's plausible we could see some
>amount of geography reflected in the telephone number, just due to the
>way they're assigned.  That's how I interpreted Pierce's comments earlier.
>
>Cheers,
>
>tim
>
>-----Original Message-----
>From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
>Sent: Monday, December 14, 2015 2:10 PM
>To: Gorman, Pierce A [CTO]; modern@ietf.org
>Subject: [E] Re: [Modern] Problem statement draft as working group
>document
>
>You seem to be trying to make a different point - one about numbering
>authorities.  The original point is about network architecture.
>
>On 12/14/15 2:58 PM, "Gorman, Pierce A [CTO]" 
>wrote:
>
>>Replace "Numbering, interconnection and routing are highly dependent on
>>geography: the PSTN was carefully designed to delegate switching
>>intelligence geographically."
>>
>>With " Numbering, interconnection and routing are CURRENTLY highly
>>dependent on geography:  the PSTN NUMBERING AUTHORITY was carefully
>>designed to delegate NUMBERING AUTHORITY geographically.
>>
>>
>>-----Original Message-----
>>From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
>>Sent: December 14, 2015 1:54 PM
>>To: PFAUTZ, PENN L ; modern@ietf.org
>>Subject: Re: [Modern] Problem statement draft as working group document
>>
>>WRT porting process:
>>This doesn't address policy.  There is no way for a user to prove to a
>>service provider that they do indeed have authority over the number.
>>It suggests that there be a technical solution, a verifiable
>>credential, that a user can submit to a service provider to prove they
>>have authority.
>>They have authority today, there's just no way to prove it.
>>
>>WRT interconnection:
>>The point of that paragraph is that current numbering is highly
>>dependent on geography, whereas in an IP environment it would be
>>independent of geography.  In an IP environment it should be different.
>>How about replacing the second sentence with:
>>"Numbering, interconnection and routing are highly dependent on
>>geography:
>>the PSTN was carefully designed to delegate switching intelligence
>>geographically."
>>
>>
>>On 12/14/15 2:26 PM, "PFAUTZ, PENN L"  wrote:
>>
>>>All,
>>>It's statements like
>>>" Ideally the user would have full control of their TN and
>>>   would drive the porting process on their own rather than rely on
>>>   complex and time consuming back office processes among multiple
>>>   service providers."
>>>
>>>that make a policy statement which concern me.
>>>
>>>As to Tom's question, it was the statement " Most TNs today are
>>>assigned to specific geographies, at both an
>>>   international level and within national numbering plans.  This has
>>>   shaped the way that service providers interconnect"
>>>
>>>I think it was the reverse - numbering followed interconnection - and
>>>the mechanisms I need for numbering will depend on the types of
>>>interconnection I have to support.
>>>
>>>So, yes I do object to specifics in the document as opposed to the
>>>enterprise as a whole.
>>>
>>>Penn Pfautz
>>>AT&T Global Connection Management
>>>
>>>
>>>-----Original Message-----
>>>From: Adam Roach [mailto:adam@nostrum.com]
>>>Sent: Monday, December 14, 2015 1:53 PM
>>>To: Steve Donovan; modern@ietf.org
>>>Subject: Re: [Modern] Problem statement draft as working group
>>>document
>>>
>>>On 12/10/15 12:40, Steve Donovan wrote:
>>>> There has been no response to this so I'm going to suggest we put a
>>>> deadline on opinions.
>>>>
>>>> Please express your opinion on making
>>>> draft-peterson-modern-problems-02 a working group document before
>>>> Thursday, December 17th.
>>>>
>>>> It is important that anyone who supports the promotion of the
>>>> document also express their opinion.
>>>
>>>I think this document is a good starting point for outlining the basic
>>>shape of the problem and the use cases MODERN is intended to address.
>>>
>>>I'll note that on-list objections so far seem to be attempting to
>>>re-litigate the formation of the working group rather than making
>>>progress towards its milestones. As has been long established (at
>>>least since the 2002 formation of XMPP), the decision to work on a
>>>problem in the IETF is based on the following criteria: "is it
>>>technically credible, are people willing to work on it, are people
>>>willing to use it?" And, in particular: "we should be deciding things
>>>based on the number of folks who want to do things, not the number
>>>opposed."
>>>
>>>In terms of considering adoption of this specific document, I think we
>>>need to be careful to parse out objections to its contents versus
>>>objections to MODERN's very existence. So far, I have seen no on-list
>>>objections that fall in the first category.
>>>
>>>/a
>>>
>>>
>>>_______________________________________________
>>>Modern mailing list
>>>Modern@ietf.org
>>>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail
>>>m
>>>an_
>>>listinfo_modern&d=3DCwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve=
eIDc
>>>L
>>>ext
>>>Z1ooNcfp01IYIaVqsORjI&m=3Db8Du8PEdrEZo_LLqNvw5JrZtUM64muibjcmAAkrALxM&s=
=3D
>>>E JyT AVbeKglij7G7DiYeWWywwrHAbKhJQYMH8snPpFg&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=3DCwIFAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufvee=
IDcL
>>ext=20
>>Z1ooNcfp01IYIaVqsORjI&m=3DwX7NaCp4TR1we4d444AWJk4h5Znti2aqix5Cr5-fxCY&s=
=3Do
>>l3y MdIchtzVnkdtU27FYlKIZ0SFMiXd-GbOP0BEn08&e=3D
>>
>>________________________________
>>
>>This e-mail may contain Sprint proprietary information intended for the
>>sole use of the recipient(s). Any use by others is prohibited. If you
>>are not the intended recipient, please contact the sender and delete
>>all copies of the message.
>
>_______________________________________________
>Modern mailing list
>Modern@ietf.org
>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma=
n_
>listinfo_modern&d=3DCwIFAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI=
DcLext
>Z1ooNcfp01IYIaVqsORjI&m=3DRdx7-8i3VcWIAoyjuHY8EWVXuyy7X_qcJD7BhgwEVnc&s=3D=
MGrx
>_Tru6e5kJ2dcMHx09Rs9oXDUyD3XY9_sUuna0l4&e=3D=20


--_002_D295B33632EB8tommcgarryneustarbiz_
Content-Type: application/xml; name="default.xml"
Content-Description: default.xml
Content-Disposition: attachment; filename="default.xml"; size=3222;
	creation-date="Tue, 15 Dec 2015 17:18:21 GMT";
	modification-date="Tue, 15 Dec 2015 17:18:21 GMT"
Content-ID: <7747007538F989448802046B501F9583@neustar.biz>
Content-Transfer-Encoding: base64

UEsDBBQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbKyRy2rDMBBF
94X+g9C22HK6KKXYzqKPXR+L9AMGeWyL2CMhTULy9x07LpQSAoVuBNLMvffMqFwfxkHtMSbnqdKr
vNAKyfrGUVfpz81Ldq9VYqAGBk9Y6SMmva6vr8rNMWBSoqZU6Z45PBiTbI8jpNwHJKm0Po7Aco2d
CWC30KG5LYo7Yz0xEmc8eei6fMIWdgOr54M8n0hErtXjqW+KqjSEMDgLLKBmqpqzuohDuiDcU/OL
LlvIclHO5ql3Id0sCe+ymugaVB8Q+Q1G4TAsQ+LP8xVIRov5ZeYz0b5tncXG290o68hn48XsTwCr
/4n+zjTz39ZfAAAA//8DAFBLAwQUAAYACAAAACEApdan58AAAAA2AQAACwAAAF9yZWxzLy5yZWxz
hI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb69tPxwYKuwiEpO/3qT3+rov54ZTn
IBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJ
ENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6PqMn/s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/j
U72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAdGhlbWUv
dGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzMTQrDIBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg0p/b
1+XjgzfO3xTVm0sNWSycBw2KZc0uiLfwfCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPVkIWt
td0g1rUr1SHvLN1euSRqPYtHV+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQAhWqKE
IQcAANsdAAAWAAAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbOxZT28bRRS/I/EdRnsvsRMnTaI6VezY
DbRpo9gt6nG8O/ZOM7uzmhkn8Q21RyQkREEcqMSNAwIqtRKX8mkCRVCkfgXezOyud+Jxk5QAFTSH
1jv7e2/e+70/82evXD1KGDogQlKeNoP6e7UAkTTkEU1HzeB2v3tpNUBS4TTCjKekGUyIDK5uvPvO
FbyuYpIQBPKpXMfNIFYqW19YkCEMY/kez0gK74ZcJFjBoxgtRAIfgt6ELSzWaisLCaZpgFKcgNpb
wyENCeprlcFGobzD4DFVUg+ETPS0auJIGGy0X9cIOZFtJtABZs0A5on4YZ8cqQAxLBW8aAY18xcs
bFxZwOu5EFNzZCtyXfOXy+UC0f6imVOMBuWk9W5j7fJWqd8AmJrFdTqddqde6jMAHIbgqbWlqrPR
Xa23Cp0VkP05q7tdW641XHxF/9KMzWutVmt5LbfFKjUg+7Mxg1+trTQ2Fx28AVn88gy+0dpst1cc
vAFZ/MoMvnt5baXh4g0oZjTdn0HrgHa7ufYSMuRs2wtfBfhqLYdPUZANZXbpKYY8VfNyLcH3uOgC
QAMZVjRFapKRIQ4hi9uY0YGgegK8TnDljR0K5cyQngvJUNBMNYMPMgwVMdX38tl3L589Qcf3nx7f
//H4wYPj+z9YRY7UNk5HVakX33z6x6OP0O9Pvn7x8HM/Xlbxv3z/8c8/feYHQvlMzXn+xeNfnz5+
/uUnv3370APfFHhQhfdpQiS6SQ7RHk/AMcOKazkZiPNJ9GNMqxKb6UjiFOtZPPo7KnbQNyeYYQ+u
RVwG7whoHz7gtfE9x+BeLMYqj7fj2fU4cYA7nLMWF14Wruu5KjT3x+nIP7kYV3F7GB/45m7j1Ilv
Z5xB36Q+le2YOGbuMpwqPCIpUUi/4/uEePi6S6nD6w4NBZd8qNBdilqYeinp04GTTVOhbZpAXCY+
AyHeDjc7d1CLM5/XW+TARUJVYOYxvk+YQ+M1PFY48ans44RVCb+BVewzsjcRYRXXkQoiPSKMo05E
pPTJ3BLgbyXo16F1+MO+wyaJixSK7vt03sCcV5FbfL8d4yTzYXs0javY9+U+pChGu1z54DvcrRD9
DHHA6dxw36HECffp3eA2HTkmTRNEvxkLTyyvEe7kb2/ChpiYVgNN3enVCU1f1bgT6Nu54xfXuKFV
Pv/qkcfuN7VlbwIJvprZPtGo5+FOtuc2FxF987vzFh6nuwQKYnaJetuc3zbn4D/fnOfV88W35GkX
hgatt0x2o2223cncXfeQMtZTE0ZuSLPxlrD2RF0Y1HLmxEnKU1gWw09dyTCBgxsJbGSQ4OpDquJe
jDPYtNcDrWQkc9UjiTIu4bBohr26NR42/soeNZf1IcR2DonVDo/s8JIeLs4apRpj1cgcaIuJlrSC
s062dDlXCr69zmR1bdSZZ6sb00xTdGYrXdYUm0M5UF66BoMlm7CpQbAVApZX4Myvp4bDDmYk0rzb
GBVhMVH4e0KUe20diXFEbIic4QqbdRO7IoVm/NPu2Rw5H5sla0Da6UaYtJifP2ckuVAwJRkET1YT
S6u1xVJ02AzWlheXAxTirBkM4ZgLP5MMgib1NhCzEdwVhUrYrD21Fk2RTj1e82dVHW4u5hSMU8aZ
kGoLy9jG0LzKQ8VSPZO1f3G5oZPtYhzwNJOzWbG0Cinyr1kBoXZDS4ZDEqpqsCsjmjv7mHdCPlZE
9OLoEA3YWOxhCD9wqv2JqITbClPQ+gGu1jTb5pXbW/NOU73QMjg7jlkW47xb6quZouIs3PST0gbz
VDEPfPPabpw7vyu64i/KlWoa/89c0csBXB4sRToCIdzsCox0pTQDLlTMoQtlMQ27AtZ90zsgW+B6
Fl4D+XC/bP4X5ED/b2vO6jBlDWdAtUdHSFBYTlQsCNmFtmSy7xRl9XzpsSpZrshkVMVcmVmzB+SA
sL7ugSu6BwcohlQ33SRvAwZ3Mv/c57yCBiO9R6nWm9PJyqXT1sA/vXGxxQxOndhL6Pwt+C9NLFf3
6epn5Y14sUZWHdEvprukRlEVzuK3tpZP9ZomnGUBrqy1tmPNeLy4XBgHUZz1GAbL/UwGV0BI/wPr
HxUhsx8r9ILa53vQWxF8e7D8IcjqS7qrQQbpBml/DWDfYwdtMmlVltp856NZKxbrC96olvOeIFtb
dpZ4n5PschPlTufU4kWSnTPscG3H5lINkT1ZojA0LM4hJjDmK1f1QxQf3INAb8GV/5jZT1MygydT
B9muMNk14NEk/8mkXXBt1ukzjEaydI8MEY2OivNHyYQtIft5pNgiG7QW04lWCi75Dg2uYI7Xona1
LIUXTxcuJczM0LJLYXOX5lMAH8fyxq2PdoC3TdZ6rYurYIqlf4WyMxjvp8x78jkrZfag+MpAvQZl
6ujVlOVMAXmziQefNwWGo1fP9F9YdGymm5Td+BMAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAA
GwEAACcAAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeC
dwhvb9O6EJEm3YjQrdQDhOQ1DTY/JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjs
jkBSFk6J2TtksGCCjm837RVnkUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9
oPGbAXzFJL1iEHvVABmWUJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8D
AFBLAQItABQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9U
eXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAALQEAAF9y
ZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAFgIAAHRo
ZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAAACEAIVqihCEHAADbHQAAFgAA
AAAAAAAAAAAAAADTAgAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN0ZCf
tgAAABsBAAAnAAAAAAAAAAAAAAAAACgKAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIu
eG1sLnJlbHNQSwUGAAAAAAUABQBdAQAAIwsAAAAA

--_002_D295B33632EB8tommcgarryneustarbiz_--


From nobody Tue Dec 15 09:39:53 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB3B1A90F6 for ; Tue, 15 Dec 2015 09:39:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level: 
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 02VvWG3UCkxG for ; Tue, 15 Dec 2015 09:39:49 -0800 (PST)
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 B69831A9138 for ; Tue, 15 Dec 2015 09:39:40 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 7DCAFC09C526; Tue, 15 Dec 2015 17:39:36 +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 tBFHdcbC003584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Dec 2015 18:39:38 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.213]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 15 Dec 2015 18:39:38 +0100
From: "DRAGE, Keith (Keith)" 
To: "McGarry, Tom" , "Dwight, Timothy M (Tim)" , "modern@ietf.org" 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHRNqCj1eRf6wrMbkWZW9juihGHiJ7KzKmAgAAHuICAAAE8AIAAAzqAgAAKF4CAAVg+gIAAFeOg
Date: Tue, 15 Dec 2015 17:39:37 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8BADE248A2@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <2B0F677F0B95454297753F58D4A07FA30282E7193A@FHDP1LUMXC7V31.us.one.verizon.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.39]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 15 Dec 2015 17:39:52 -0000

Part of this problem is the use of this "TN" or its expansion to "telephone=
 number", because it has no formal definition.

As an E.164 number, it identifies the subscriber, not the line termination =
of the subscriber, and not the routeing. Because telephone number has no de=
finition, I do not think it is possible to be so emphatic. If one insists o=
n using TN, then either someone has to invent a definition that says it ide=
ntifies the subscriber, or always qualify the term with this information.

Regards

Keith

-----Original Message-----
From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: 15 December 2015 17:18
To: Dwight, Timothy M (Tim); modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

Yes, on IP networks TNs are identifiers and not addresses (as they are on T=
DM networks).=20

I also agree that there can still be a linkage between TNs and geography in=
 an all-IP environment.  The draft does not say that there will be no linka=
ge whatsoever.

On 12/14/15 3:46 PM, "Dwight, Timothy M (Tim)"
 wrote:

>Tom,
>
>What I think you're saying is that the function of a telephone number=20
>in an "all IP world" is expected to be different than in the PSTN.
>
>Telephone numbers are used for routing in the PSTN, which is the=20
>fundamental reason their assignment generally reflects the topology of
>the network.   The PSTN routes on number prefixes, as does the Internet.
>There are differences in the details, but the fundamental need for=20
>address summarization is common.  This results in address assignments=20
>that reflect network topology.
>
>I *think* the reason for the assumption that telephone number=20
>assignment in an all-IP world need not reflect geography is that it's=20
>assumed that telephone numbers in that environment are no longer treated a=
s addresses.
>  Instead they are generally expected to be identifiers, mapped to=20
>network addresses through some sort of translation process.  Right?
>
>If so I would buy that the rationale for embedding geography into=20
>telephone numbers, in an "all IP world", is different than it has been=20
>in the PSTN.  I don't think it's gone though.  As a simple example, we=20
>will probably need to maintain the notion of a "country code", because=20
>telephone numbers are national resources and subject to national laws=20
>and regulation.  It might also be that within a country, number=20
>assignment is performed by agencies responsible for certain geographic=20
>areas.  It seems technically possible that they all share a single pool=20
>of numbers, but some countries might elect not to.  They might prefer=20
>instead to partition the address space.  Such partitioning would be reflec=
ted in the
>addresses they assign.   So I think it's plausible we could see some
>amount of geography reflected in the telephone number, just due to the=20
>way they're assigned.  That's how I interpreted Pierce's comments earlier.
>
>Cheers,
>
>tim
>
>-----Original Message-----
>From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
>Sent: Monday, December 14, 2015 2:10 PM
>To: Gorman, Pierce A [CTO]; modern@ietf.org
>Subject: [E] Re: [Modern] Problem statement draft as working group=20
>document
>
>You seem to be trying to make a different point - one about numbering=20
>authorities.  The original point is about network architecture.
>
>On 12/14/15 2:58 PM, "Gorman, Pierce A [CTO]"=20
>
>wrote:
>
>>Replace "Numbering, interconnection and routing are highly dependent=20
>>on
>>geography: the PSTN was carefully designed to delegate switching=20
>>intelligence geographically."
>>
>>With " Numbering, interconnection and routing are CURRENTLY highly=20
>>dependent on geography:  the PSTN NUMBERING AUTHORITY was carefully=20
>>designed to delegate NUMBERING AUTHORITY geographically.
>>
>>
>>-----Original Message-----
>>From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry,=20
>>Tom
>>Sent: December 14, 2015 1:54 PM
>>To: PFAUTZ, PENN L ; modern@ietf.org
>>Subject: Re: [Modern] Problem statement draft as working group=20
>>document
>>
>>WRT porting process:
>>This doesn't address policy.  There is no way for a user to prove to a=20
>>service provider that they do indeed have authority over the number.
>>It suggests that there be a technical solution, a verifiable=20
>>credential, that a user can submit to a service provider to prove they=20
>>have authority.
>>They have authority today, there's just no way to prove it.
>>
>>WRT interconnection:
>>The point of that paragraph is that current numbering is highly=20
>>dependent on geography, whereas in an IP environment it would be=20
>>independent of geography.  In an IP environment it should be different.
>>How about replacing the second sentence with:
>>"Numbering, interconnection and routing are highly dependent on
>>geography:
>>the PSTN was carefully designed to delegate switching intelligence=20
>>geographically."
>>
>>
>>On 12/14/15 2:26 PM, "PFAUTZ, PENN L"  wrote:
>>
>>>All,
>>>It's statements like
>>>" Ideally the user would have full control of their TN and
>>>   would drive the porting process on their own rather than rely on
>>>   complex and time consuming back office processes among multiple
>>>   service providers."
>>>
>>>that make a policy statement which concern me.
>>>
>>>As to Tom's question, it was the statement " Most TNs today are=20
>>>assigned to specific geographies, at both an
>>>   international level and within national numbering plans.  This has
>>>   shaped the way that service providers interconnect"
>>>
>>>I think it was the reverse - numbering followed interconnection - and=20
>>>the mechanisms I need for numbering will depend on the types of=20
>>>interconnection I have to support.
>>>
>>>So, yes I do object to specifics in the document as opposed to the=20
>>>enterprise as a whole.
>>>
>>>Penn Pfautz
>>>AT&T Global Connection Management
>>>
>>>
>>>-----Original Message-----
>>>From: Adam Roach [mailto:adam@nostrum.com]
>>>Sent: Monday, December 14, 2015 1:53 PM
>>>To: Steve Donovan; modern@ietf.org
>>>Subject: Re: [Modern] Problem statement draft as working group=20
>>>document
>>>
>>>On 12/10/15 12:40, Steve Donovan wrote:
>>>> There has been no response to this so I'm going to suggest we put a=20
>>>> deadline on opinions.
>>>>
>>>> Please express your opinion on making
>>>> draft-peterson-modern-problems-02 a working group document before=20
>>>> Thursday, December 17th.
>>>>
>>>> It is important that anyone who supports the promotion of the=20
>>>> document also express their opinion.
>>>
>>>I think this document is a good starting point for outlining the=20
>>>basic shape of the problem and the use cases MODERN is intended to addre=
ss.
>>>
>>>I'll note that on-list objections so far seem to be attempting to=20
>>>re-litigate the formation of the working group rather than making=20
>>>progress towards its milestones. As has been long established (at=20
>>>least since the 2002 formation of XMPP), the decision to work on a=20
>>>problem in the IETF is based on the following criteria: "is it=20
>>>technically credible, are people willing to work on it, are people=20
>>>willing to use it?" And, in particular: "we should be deciding things=20
>>>based on the number of folks who want to do things, not the number=20
>>>opposed."
>>>
>>>In terms of considering adoption of this specific document, I think=20
>>>we need to be careful to parse out objections to its contents versus=20
>>>objections to MODERN's very existence. So far, I have seen no on-list=20
>>>objections that fall in the first category.
>>>
>>>/a
>>>
>>>
>>>_______________________________________________
>>>Modern mailing list
>>>Modern@ietf.org
>>>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai
>>>l
>>>m
>>>an_
>>>listinfo_modern&d=3DCwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve=
eID
>>>c
>>>L
>>>ext
>>>Z1ooNcfp01IYIaVqsORjI&m=3Db8Du8PEdrEZo_LLqNvw5JrZtUM64muibjcmAAkrALxM&s
>>>=3D E JyT AVbeKglij7G7DiYeWWywwrHAbKhJQYMH8snPpFg&e=3D
>>
>>_______________________________________________
>>Modern mailing list
>>Modern@ietf.org
>>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail
>>m
>>an_
>>listinfo_modern&d=3DCwIFAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufvee=
IDc
>>L
>>ext
>>Z1ooNcfp01IYIaVqsORjI&m=3DwX7NaCp4TR1we4d444AWJk4h5Znti2aqix5Cr5-fxCY&s=
=3D
>>o l3y MdIchtzVnkdtU27FYlKIZ0SFMiXd-GbOP0BEn08&e=3D
>>
>>________________________________
>>
>>This e-mail may contain Sprint proprietary information intended for=20
>>the sole use of the recipient(s). Any use by others is prohibited. If=20
>>you are not the intended recipient, please contact the sender and=20
>>delete all copies of the message.
>
>_______________________________________________
>Modern mailing list
>Modern@ietf.org
>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm
>an_=20
>listinfo_modern&d=3DCwIFAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI=
DcL
>ext=20
>Z1ooNcfp01IYIaVqsORjI&m=3DRdx7-8i3VcWIAoyjuHY8EWVXuyy7X_qcJD7BhgwEVnc&s=3D=
M
>Grx _Tru6e5kJ2dcMHx09Rs9oXDUyD3XY9_sUuna0l4&e=3D


From nobody Tue Dec 15 09:54: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 3ED821A9138 for ; Tue, 15 Dec 2015 09:54:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bN2A1AS-MU5W for ; Tue, 15 Dec 2015 09:54:13 -0800 (PST)
Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 186CE1A9121 for ; Tue, 15 Dec 2015 09:54:12 -0800 (PST)
Received: from smtp3.infomaniak.ch (smtp3.infomaniak.ch [84.16.68.91]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBFHsAwJ011456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 15 Dec 2015 18:54:10 +0100
Received: from Timea (156.227.63.81.dynamic.wline.res.cust.swisscom.ch [81.63.227.156]) (authenticated bits=0) by smtp3.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBFHs9TP017147; Tue, 15 Dec 2015 18:54:09 +0100
From: "Richard Hill" 
To: "'McGarry, Tom'" , "'Dwight, Timothy M \(Tim\)'" , 
References: <2B0F677F0B95454297753F58D4A07FA30282E7193A@FHDP1LUMXC7V31.us.one.verizon.com> 
In-Reply-To: 
Date: Tue, 15 Dec 2015 18:55:08 +0100
Message-ID: <015701d13761$bd368fc0$37a3af40$@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: AQHRHl26DyraNZUDF0WIF1b3d5Qwlp7FC3CAgAZM7ICAAAlogP//s+EAgABVEwD//69hAIAAAnfggAFf4YCAAAm2wA==
Content-Language: fr-ch
X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8
X-Antivirus-Code: 0x100000
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 15 Dec 2015 17:54:18 -0000

Please see below.

Thanks and best,
Richard

> -----Original Message-----
> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, =
Tom
> Sent: mardi, 15. d=E9cembre 2015 18:18
> To: Dwight, Timothy M (Tim); modern@ietf.org
> Subject: Re: [Modern] Problem statement draft as working group =
document
>=20
> Yes, on IP networks TNs are identifiers and not addresses (as they are
> on TDM networks).

As I already said in a previous E-Mail, E.164 numbers are names
(identifiers) in general, even on non-IP networks, provided that SS7 is
used, which is usually the case.

SNIP


From nobody Tue Dec 15 10:03: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 8648E1A9170 for ; Tue, 15 Dec 2015 10:03:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xx1Kxzo276Me for ; Tue, 15 Dec 2015 10:03:13 -0800 (PST)
Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 236AA1A9238 for ; Tue, 15 Dec 2015 10:03:06 -0800 (PST)
Received: from smtp3.infomaniak.ch (smtp3.infomaniak.ch [84.16.68.91]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBFI34Kt026317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 15 Dec 2015 19:03:04 +0100
Received: from Timea (156.227.63.81.dynamic.wline.res.cust.swisscom.ch [81.63.227.156]) (authenticated bits=0) by smtp3.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBFI32EE008375; Tue, 15 Dec 2015 19:03:02 +0100
From: "Richard Hill" 
To: "'Gorman, Pierce A [CTO]'" , "'Dwight, Timothy M \(Tim\)'" , "'McGarry, Tom'" , 
References:   <2B0F677F0B95454297753F58D4A07FA30282E7193A@FHDP1LUMXC7V31.us.one.verizon.com> <007601d13702$40a989d0$c1fc9d70$@ch> 
In-Reply-To: 
Date: Tue, 15 Dec 2015 19:04:01 +0100
Message-ID: <015a01d13762$fa7ca350$ef75e9f0$@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: AQHRHl26KCigIa6jakmAIZNM6lCGV57FC3CAgAZM7ICAAAlogP//s+EAgABVEwD//69hAIAAAnfggACpdlCAAKdXgIAAGlyw
Content-Language: fr-ch
X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8
X-Antivirus-Code: 0x100000
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 15 Dec 2015 18:03:15 -0000

Please see below.

Thanks and best,
Richard

> -----Original Message-----
> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Gorman,
> Pierce A [CTO]
> Sent: mardi, 15. d=E9cembre 2015 18:05
> To: Richard Hill; 'Dwight, Timothy M (Tim)'; 'McGarry, Tom';
> modern@ietf.org
> Subject: Re: [Modern] Problem statement draft as working group =
document
>=20
> Comments in-line.
>=20
> Pierce
>=20
> -----Original Message-----
> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard =
Hill
> Sent: December 15, 2015 12:32 AM
> To: 'Dwight, Timothy M (Tim)' ; 'McGarry,
> Tom' ; Gorman, Pierce A [CTO]
> ; modern@ietf.org
> Subject: Re: [Modern] Problem statement draft as working group =
document
>=20
> Please see embedded comments below.
>=20
> Thanks and best,
> Richard
>=20
> > -----Original Message-----
> > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Dwight,
> > Timothy M (Tim)
> > Sent: Monday, December 14, 2015 21:46
> > To: McGarry, Tom; Gorman, Pierce A [CTO]; modern@ietf.org
> > Subject: Re: [Modern] Problem statement draft as working group
> > document
> >
> > Tom,
> >
> > What I think you're saying is that the function of a telephone =
number
> > in an "all IP world" is expected to be different than in the PSTN.
> >
> > Telephone numbers are used for routing in the PSTN,
>=20
> That was true back in the old days of rotary dialing, but it is to a
> large extent no longer the case at the national level with SS7. Many
> countries have full fixed number portability, so the E.164 number no
> longer has any geographical significance.
>=20
> PG-> SS7 is irrelevant to the number assignment question/issue.=20

Let's agree to disagree on that.

> I'll
> agree Non-geographic portability (NGP) will soon be required per
> regulation and supported.  NGP does not inherently remove the
> geographical-ness of previously assigned numbers, or their state PUC
> regulated assignment process (for the NANP at least).=20

I'm snipping what follows because it appears to me to focus on the NANP. =
 I
thought that the work of this group was supposed to apply to telephone
numbers in general, not just to the NANP. If it is meant to apply
specifically to the NANP, then perhaps that should be stated explicitly.

SNIP

>=20
> Actually in today's telephone network, the E.164 number is a name,
> analogous to Internet domain names.  The telephony equivalent of an IP
> address is the IMSI (E.212) for mobile and ISPC/SANC (Q.709) for =
fixed.
>=20
> PG-> I would use the example of portability as an example exactly
> opposite to your assertion that E.164 numbers are analagous to =
Internet
> domain names which are clearly not portable (as I was reminded by my
> ISP e-mail service recently). =20

??? Is that some US specificity? I can move any of my ".ch" domain names =
to
any ISP at any time. And, for all I know, my ISP has moved them around =
its
servers, so that that IP addresses corresponding to my domain names have
changed over time.

Or are you referring to a domain name that you don't own, such as
"hotmail.com"?Obviously you cannot move that, but its owner can move it.

SNIP



From nobody Tue Dec 15 10:44: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 80BA51AC3BF for ; Tue, 15 Dec 2015 10:44:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCOxArv4EtuD for ; Tue, 15 Dec 2015 10:43:59 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0131.outbound.protection.outlook.com [65.55.169.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEAEB1AC3B5 for ; Tue, 15 Dec 2015 10:43:57 -0800 (PST)
Received: from BN1BFFO11FD032.protection.gbl (10.58.144.33) by BN1BFFO11HUB045.protection.gbl (10.58.144.192) with Microsoft SMTP Server (TLS) id 15.1.346.13; Tue, 15 Dec 2015 18:43:52 +0000
Authentication-Results: spf=pass (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com;
Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.38 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.38; helo=plsapdm2.corp.sprint.com;
Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BN1BFFO11FD032.mail.protection.outlook.com (10.58.144.95) with Microsoft SMTP Server (TLS) id 15.1.346.13 via Frontend Transport; Tue, 15 Dec 2015 18:43:52 +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 tBFGVTEO030349;  Tue, 15 Dec 2015 12:43:52 -0600
Received: from prewe13m08.ad.sprint.com (prewe13m08.corp.sprint.com [144.226.128.27]) by plsapdm2.corp.sprint.com with ESMTP id 1yrj86ftgt-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 15 Dec 2015 12:43:52 -0600
Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M08.ad.sprint.com (2002:90e2:801b::90e2:801b) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 15 Dec 2015 13:43:50 -0500
Received: from PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed]) by PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed%24]) with mapi id 15.00.1076.000; Tue, 15 Dec 2015 12:43:50 -0600
From: "Gorman, Pierce A [CTO]" 
To: Richard Hill , "'Dwight, Timothy M (Tim)'" , "'McGarry, Tom'" , "modern@ietf.org" 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHRHl26KCigIa6jakmAIZNM6lCGV57FC3CAgAZM7ICAAAlogP//s+EAgABVEwD//69hAIAAAnfggACpdlCAAKdXgIAAGlywgAAJZsA=
Date: Tue, 15 Dec 2015 18:43:49 +0000
Message-ID: 
References:   <2B0F677F0B95454297753F58D4A07FA30282E7193A@FHDP1LUMXC7V31.us.one.verizon.com> <007601d13702$40a989d0$c1fc9d70$@ch>  <015a01d13762$fa7ca350$ef75e9f0$@ch>
In-Reply-To: <015a01d13762$fa7ca350$ef75e9f0$@ch>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.214.116.44]
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; BN1BFFO11FD032; 1:d2Q91884ti87rd7DS0mfsvEHQxCzWgrviSplOjKmYXyhewZhiWY4YW990T3aQJh8acRTTcVwvNkRqzyMzLvR53ShHADAvrS3cwizqCSRlnCqs1p8iQJalvi9DnoHlUxzpAnMPRLuuyaCR7BhiRw1cWz2cR+o0QVRcGS71pvv94kqb+87jyQwMyB0c02L1yXzwf30FbJ/syvRdaHgCkNYbDMPFTkTySlJ7BE2QnK7slDr8PBagXjTTz7EdBEiintVsgOqTvk071k72WqNDmkr0wYLon3G21QelkEv7rSA35lKpCRC644UUYR7+8gEN0YvrUuVZcl8QbFzsHX3c1RtG1fCLIxWEnM7yuC2mfgQLdD1rPUTxn9eY9/McoltVJxJ2lX8RDkoLX9mrTmVOSn18Q==
X-Forefront-Antispam-Report: CIP:144.230.172.38; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(377454003)(189002)(199003)(13464003)(97736004)(19580405001)(3846002)(106116001)(33646002)(1220700001)(189998001)(50466002)(2950100001)(11100500001)(81156007)(106466001)(5003600100002)(86362001)(5004730100002)(108616004)(5001960100002)(1096002)(19580395003)(76176999)(93886004)(107886002)(6116002)(5008740100001)(102836003)(54356999)(92566002)(50986999)(586003)(2501003)(24736003)(5001770100001)(2900100001)(23756003)(87936001)(47776003)(6806005)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB045; H:plsapdm2.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB045; 2:e0cjj0RYBGCIyxO1OpZ1bQVeRM78Utk8m0snwvQkue+sa3Wlgit2+UvGTbpbuZEDRxMA3NPVvhYbQ18JT+HzknM45AWmX/B0U3mxXoN8LZdC9kF38mNaH+GVOTLXjnE3YHUD7QE2XzVSywOrWai6MQ==; 3:EPyUdTblyBFP/82DkEFlBC6LjH9z4jvRet51T6VZA2yp6vs3XlVIuesfLNCOPkti3TsA+19FfLoTS6DHMgXSDe0ij6omtaIMsVoG4aqsunUACcDzJgc5AcBV7IzlBHvfhOaeNw+RYK+u/KwVYYEp++Fegg80+hGOYja14HhefbkL/1rxYXUEf4HgxBGq5ys9xCz03Nl5qmqPks3yOXgcz1u2BU1T1oz4RPTw2P+L4R8Kv7Vet1Dus4lKXMCp6Yvea6ZA7bVDGpobf/zPPC5fSw==; 25:byA8BTLT7zafurNsoACnL1veNrJtMqk1VBFrOL8ZKes+QPGr8YV6oGFh+BZmrZTM6hpXxvWd4HKIwSgFuyYGwdU5TZiFfaexvg3/BdEhSsH3JFJiTAWk1RB+hqch/Zg2w/gsyC+O6uFThKV+lIfDeiVkRyOS1ZYzDWxEVXKr6UzLZGVjdnJPnixrnvcLb3QdzzYX16U5n4QCdwR9X6Frkho2H0RYclflogX2OzibBE8KsnW4JaaA+Ozey3/YHtJ3tVpsJ1wD+zJLOIv1vmEG+A==
X-Exchange-Antispam-Report-Test: UriScan:; BCL:0; PCL:0; RULEID:(8251501002);  SRVR:BN1BFFO11HUB045; UriScan:(18430343700868)(194151415913766); 
X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB045; 20:cgv98SR8MaGvSzDWnTqw6bL1r9hJAvuYRMP9wH3MhoVHHwFFFcE2O2HAGKWAxPwYJbVoPK1iueKzylHJQqpVnRppEhWODSqmjJo2lma7ZuZHZyV8wvAi+NZVMz2r9Buv6F8CjNp0IdBUHHsGLz66CNLYDo3+yW5P11RNIetITlBCQMbtVh1e8LqwSZ5qJc1PVSufeBnOhw4COmV/TsshDfDfYhmkEFZDl1S5jpbMGCwMTGgDhObGtmxZKS3MRjQT; 4:UJGAGJEGWwZRGEx2qgCtUtqOZLLTMY8V52clB9fdzXVQpBcwQQ64iRXITHfka2SB11w0sdmbuK3IOyDoUmvWhl3BTkVIb6KfYaRPjkqJgxk2WxlBuRr5eFyG2n0T6uTQZVJWdEiMaTHorO+Mdeax3sJYPBELPp/1gGA8lLzTj/xKcMEfmD5CH87sY+4WDy5pdnQFWpIiBEwfIZ13R0iKhgZBG7Ua4Job7ea02lxemS93vovdmN2fNRqS3ZAsHFWEK2UnYOFQmvdUud3pEQ+D+5mbXFBnn3XxgwJFWWfn0QP8axGSTkLLRsOiQGhDdB2I98B2bmQArfgWJDlZV9nkfr2VZAcLZgDPquXT7sc5Uv5GETtuXqi+0OOHi491Cfwgz+BLKSbPAFOofs5iH2gzcApBb+vGg5MmZxhzD8C2wzl05Raa3J2eQhP4nPxHIuueFp3Giew4OYDdPh12NVimCQ==
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046); SRVR:BN1BFFO11HUB045; BCL:0; PCL:0; RULEID:; SRVR:BN1BFFO11HUB045; 
X-Forefront-PRVS: 07915F544A
X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; BN1BFFO11HUB045; 23:c6J7H4jgHkIOd+Vt66ZBPrQQ2+7/eQ0yN8iMX?= =?iso-8859-1?Q?7EMqKhlQHAyYAWrXZGxrQbYYSZ3EAOu2KZZ1xg9/KIi6lvq5OIaH+9EkMW?= =?iso-8859-1?Q?l9cocQmQCkIPLcE+xl+RxgssGsziJAKhnOh84gtsgsmjVxOyFkSHkA6ivM?= =?iso-8859-1?Q?MHoYy5Wwo7VpdtdyIZcdWJn12fb9sCWHRuAtDARMa26dICsQe+3UwqzA/V?= =?iso-8859-1?Q?iRpDJ2y21idWABr3r5BnRcsDFXH7f1zbauvT5ZjtZFerGwL3Hnh/ai/O+t?= =?iso-8859-1?Q?Fyz7X40fXOL4eziFqhl/tKzcpaM6E0AElvEYWaBYzQjG16F4I5sRyOGb4f?= =?iso-8859-1?Q?Ufm3QHMNpkUl+YRMVk9oFjOoBWMwN2871XSkvD8mVxZQ9hyZGBfNn1AVQj?= =?iso-8859-1?Q?9ztY1ec6BPcde3wYlImXiYGKC6dh9DCFpGXQ0cbwUFdQBDuJr1K7mkCaEb?= =?iso-8859-1?Q?MXmRhm7Mhj414MnXYiQiZIskLKz9CBE2I371DtJdhX/EdIvJAolAVDjJC/?= =?iso-8859-1?Q?EMaOJ+jnCKCMM50Q1FuKarqJFJeAmcSe1cfMsy35MTv3JKeXm+9w2/f9RD?= =?iso-8859-1?Q?M9CLZcIb5wYp12BA0vfijnA0btnO7HdzvWUc7oMuhn3Q+/CHtb/5esDaq0?= =?iso-8859-1?Q?t/ebRJELRGsTvYwdESR+TRFHVon88p7G9T8vgPNFJ9b57/NIqAPBJFAjS0?= =?iso-8859-1?Q?vvzhc3tJxVBS/bvKL+dL/rFvEAbrf/snonO28GjjGC/cvNKe4Akn9OkB3A?= =?iso-8859-1?Q?1U1v165yUglLb6bIyp8TT5XKZWt5cZAcSbtnggPDfJTmoWJR66x67QX2zy?= =?iso-8859-1?Q?2TACDBjvqr2026H3iW3n2V65CNMRwQE59yUxkXvG0aASM+USzygXHOvZ7F?= =?iso-8859-1?Q?n7UcUu8F+N0YSyUuoABcuJz1UOBE13uMGy11yD2GoiC6HgGrPdEYKTnFrp?= =?iso-8859-1?Q?21bYGnLMne8+IFNiO2PPJG1Udn/utNdmUFDI0N/GtzCz5Y/vNv8+Gabm1f?= =?iso-8859-1?Q?k3B2gYWkDntkXJR1JKyYNst4TUj/S0iqDbvYjDctaNNEf0a/NBNGOvdsIL?= =?iso-8859-1?Q?pNZ0pyL2JN1tl/rJAeZiPCaq3NeTDhJnePVAfPA2POxkvj54SniLU2c0J0?= =?iso-8859-1?Q?5T1aFtn/VGusbvOWyP/UcMMKawoKQLm/0ygWejvNrGIfCRajJNGocnJq1H?= =?iso-8859-1?Q?VmC7C/Vsc9XIoclS/Ttg2xkTKrUH5FbIQsawwpU2q9h+WWH7cTwbSNVM?= =?iso-8859-1?Q?=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB045; 5:r1G8G9ioJCqre0jEOnSfF3DMK2aGWiLFtgE8jpm5OsS8CMB8NWNZH0SJvky9J9AATLZZ0yF4mI8U0elCEytFrC1gK/JWbuXsEBpWsMZPEVlWVV78OBGgYHp/no/pqMZS9idK3cktuljp3k2Gm+MAeA==; 24:ky1+JGRBlHdUY/JQWg64+eC0wPMfaoWxu2dYwmmzRob3fimQSdiNgm2r3NE7vJnIpsKfVrg5KYAur1mDaibD6iE8uT4pigb7CFaXafrrZYc=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: sprint.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Dec 2015 18:43:52.7179 (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: BN1BFFO11HUB045
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 15 Dec 2015 18:44:02 -0000

Rejoinders in-line.

-----Original Message-----
From: Richard Hill [mailto:rhill@hill-a.ch]
Sent: December 15, 2015 12:04 PM
To: Gorman, Pierce A [CTO] ; 'Dwight, Timothy M (=
Tim)' ; 'McGarry, Tom' ; modern@ietf.org
Subject: RE: [Modern] Problem statement draft as working group document

Please see below.

Thanks and best,
Richard

> -----Original Message-----
> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Gorman,
> Pierce A [CTO]
> Sent: mardi, 15. d=E9cembre 2015 18:05
> To: Richard Hill; 'Dwight, Timothy M (Tim)'; 'McGarry, Tom';
> modern@ietf.org
> Subject: Re: [Modern] Problem statement draft as working group
> document
>
> Comments in-line.
>
> Pierce
>
> -----Original Message-----
> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard
> Hill
> Sent: December 15, 2015 12:32 AM
> To: 'Dwight, Timothy M (Tim)' ; 'McGarry,
> Tom' ; Gorman, Pierce A [CTO]
> ; modern@ietf.org
> Subject: Re: [Modern] Problem statement draft as working group
> document
>
> Please see embedded comments below.
>
> Thanks and best,
> Richard
>
> > -----Original Message-----
> > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Dwight,
> > Timothy M (Tim)
> > Sent: Monday, December 14, 2015 21:46
> > To: McGarry, Tom; Gorman, Pierce A [CTO]; modern@ietf.org
> > Subject: Re: [Modern] Problem statement draft as working group
> > document
> >
> > Tom,
> >
> > What I think you're saying is that the function of a telephone
> > number in an "all IP world" is expected to be different than in the PST=
N.
> >
> > Telephone numbers are used for routing in the PSTN,
>
> That was true back in the old days of rotary dialing, but it is to a
> large extent no longer the case at the national level with SS7. Many
> countries have full fixed number portability, so the E.164 number no
> longer has any geographical significance.
>
> PG-> SS7 is irrelevant to the number assignment question/issue.

Let's agree to disagree on that.

PG-> I'd prefer to see your argument as to why you feel it is relevant, but=
 as you wish.

> I'll
> agree Non-geographic portability (NGP) will soon be required per
> regulation and supported.  NGP does not inherently remove the
> geographical-ness of previously assigned numbers, or their state PUC
> regulated assignment process (for the NANP at least).

I'm snipping what follows because it appears to me to focus on the NANP.  I=
 thought that the work of this group was supposed to apply to telephone num=
bers in general, not just to the NANP. If it is meant to apply specifically=
 to the NANP, then perhaps that should be stated explicitly.

PG->  I would argue you shouldn't have SNIPped my question, "what is it abo=
ut NGP [Non-Geographic Portability] and eroding the relationship between nu=
mbers and their geography that is a problem for MODERN to address?"

SNIP

>
> Actually in today's telephone network, the E.164 number is a name,
> analogous to Internet domain names.  The telephony equivalent of an IP
> address is the IMSI (E.212) for mobile and ISPC/SANC (Q.709) for fixed.
>
> PG-> I would use the example of portability as an example exactly
> opposite to your assertion that E.164 numbers are analagous to
> Internet domain names which are clearly not portable (as I was
> reminded by my ISP e-mail service recently).

??? Is that some US specificity? I can move any of my ".ch" domain names to=
 any ISP at any time. And, for all I know, my ISP has moved them around its=
 servers, so that that IP addresses corresponding to my domain names have c=
hanged over time.

Or are you referring to a domain name that you don't own, such as "hotmail.=
com"?Obviously you cannot move that, but its owner can move it.

PG-> While it's true you can port the user portion (as long as there isn't =
a conflict) of the URI which comprises your e-mail address, the FQDN portio=
n of your name is about as portable as the Empire State Building.  So, no, =
I would prefer telephone numbers remained more usefully differentiated in t=
heir portability as compared to e-mail addresses based on fully-qualified d=
omain names.  If MODERN proposed to make domain name addresses of the Inter=
net as portable as telephone numbers (even as portable as telephone numbers=
 in the US without NGP), many millions of e-mail users would be grateful; m=
e amongst them.  That IS a REAL problem that consumers could benefit from b=
eing solved.

SNIP



________________________________

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


From nobody Tue Dec 15 18:00:43 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157321A1A6C for ; Tue, 15 Dec 2015 18:00:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.011
X-Spam-Level: 
X-Spam-Status: No, score=-1.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHB33szVQgcX for ; Tue, 15 Dec 2015 18:00:39 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3176D1A1A64 for ; Tue, 15 Dec 2015 18:00:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=yuVN5svWcikSUArs4h+HksQTl3S7SbiSVg5TuTWKfEE=;  b=o+DhFHI7mCVeuFy2CBe6SOFJIC2b/uKskGl9/B4hWisNkQhxwC3BA+hU2+40AAcVXWTq1HfkvQUBDnzdj245mq2rYUsCcJF2qOcqHaYdSwU+TPt3JiguLXhZvZQ6LiF8HajNWs4fKlj6zIQWvUrAhWfnenTyLmlC5J1bc4goGNI=;
Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:52334 helo=[192.168.15.111]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1a91OL-0006Lr-DC for modern@ietf.org; Tue, 15 Dec 2015 18:00:38 -0800
Content-Type: multipart/signed; boundary="Apple-Mail=_27376192-DBF9-4B8F-AE13-DD09B8DC7C35"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
X-Pgp-Agent: GPGMail 2.6b2
From: Eric Burger 
In-Reply-To: <566ED5E3.9020203@usdonovans.com>
Date: Tue, 15 Dec 2015 21:00:32 -0500
Message-Id: 
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com>  <566ED5E3.9020203@usdonovans.com>
To: modern@ietf.org
X-Mailer: Apple Mail (2.3112)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 16 Dec 2015 02:00:41 -0000

--Apple-Mail=_27376192-DBF9-4B8F-AE13-DD09B8DC7C35
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_3151A3AC-099C-436A-A7EC-9A7676847568"


--Apple-Mail=_3151A3AC-099C-436A-A7EC-9A7676847568
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Simple. In over six months, there have been precisely zero substantive =
messages on the MODERN list, save your message last month asking if the =
silence means everyone thinks this is a good idea or if silence means no =
one cares.

I am glad to see my brief response just five days ago generated close to =
10% of the total number of messages on the list since the list started, =
which was close to six months before the work group was chartered. I.e., =
including all of the charter discussion.

What response did my one word email elucidate? One person saying the =
document should be adopted, one work group chair valiantly trying to say =
the document should be adopted, and a ton of folks saying it should not =
be adopted.

We neither vote nor allow mob rule. However, given no one cared =
literally one peep for over six months and only one person thinks the =
document is ready to be a work group item, we are a long, long, long way =
from adopting the document.

You do have consensus, but it is not the consensus you are looking for.



> On Dec 14, 2015, at 9:44 AM, Steve Donovan  =
wrote:
>=20
> Eric,
>=20
> Could you elaborate on why you think the document should not become a =
working group item.
> Thanks,
>=20
> Steve
>=20
> On 12/10/15 7:05 PM, Eric Burger wrote:
>> Nah. :-)
>>=20
>>> On Dec 10, 2015, at 1:40 PM, Steve Donovan =
  wrote:
>>>=20
>>> There has been no response to this so I'm going to suggest we put a =
deadline on opinions.
>>>=20
>>> Please express your opinion on making =
draft-peterson-modern-problems-02 a working group document before =
Thursday, December 17th.
>>>=20
>>> It is important that anyone who supports the promotion of the =
document also express their opinion.
>>>=20
>>> Thanks,
>>>=20
>>> Steve
>>>=20
>>> On 11/13/15 3:53 PM, Steve Donovan wrote:
>>>> All,
>>>>=20
>>>> During the IETF94 MODERN WG meeting there was consensus that =
draft-peterson-modern-problems-02 be accepted as a working group =
document.  This would be to address the architecture Architecture =
Overview milestone.
>>>>=20
>>>> It was recognized that it is not in final form but would be a good =
starting point for the architecture overview.
>>>>=20
>>>> Please comment on whether or not this should become a working group =
document.
>>>>=20
>>>> Regards,
>>>>=20
>>>> Steve
>>>>=20
>>>> _______________________________________________
>>>> Modern mailing list
>>>> Modern@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/modern =

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

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

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


--Apple-Mail=_3151A3AC-099C-436A-A7EC-9A7676847568
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Simple. In over six months, there have been precisely zero =
substantive messages on the MODERN list, save your message last month =
asking if the silence means everyone thinks this is a good idea or if =
silence means no one cares. 

I am glad to see my brief response just five days ago =
generated close to 10% of the total number of messages on the list since =
the list started, which was close to six months before the work group =
was chartered. I.e., including all of the charter discussion.

What response did my one =
word email elucidate? One person saying the document should be adopted, =
one work group chair valiantly trying to say the document should be =
adopted, and a ton of folks saying it should not be adopted.

We neither vote nor =
allow mob rule. However, given no one cared literally one peep for over =
six months and only one person thinks the document is ready to be a work =
group item, we are a long, long, long way from adopting the =
document.

You =
do have consensus, but it is not the consensus you are looking for.



On Dec 14, 2015, at 9:44 AM, =
Steve Donovan <srdonovan@usdonovans.com> wrote:


 =20
    
 =20
  

    Eric,

    

    Could you elaborate on why you think the document should not become
    a working group item.

    
 

    Thanks,

    

    Steve

    

    
On 12/10/15 7:05 PM, Eric Burger =
wrote:

    

    

      
Nah. :-)



      

        
On Dec 10, 2015, at 1:40 PM, Steve =
Donovan <srdonovan@usdonovans.com><=
/a> wrote:

There has been no response to this so I'm going to suggest we put a =
deadline on opinions.

Please express your opinion on making draft-peterson-modern-problems-02 =
a working group document before Thursday, December 17th.

It is important that anyone who supports the promotion of the document =
also express their opinion.

Thanks,

Steve

On 11/13/15 3:53 PM, Steve Donovan wrote:


        

          
All,

During the IETF94 MODERN WG meeting there was consensus that =
draft-peterson-modern-problems-02 be accepted as a working group =
document.  This would be to address the architecture Architecture =
Overview milestone.

It was recognized that it is not in final form but would be a good =
starting point for the architecture overview.

Please comment on whether or not this should become a working group =
document.

Regards,

Steve

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


        

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


      

      

      

      

      

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


    

    

  


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

=

--Apple-Mail=_3151A3AC-099C-436A-A7EC-9A7676847568--

--Apple-Mail=_27376192-DBF9-4B8F-AE13-DD09B8DC7C35
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

iQIcBAEBCAAGBQJWcMXAAAoJEORoZaSQsc1I0BMP/RCTIoNM20IiSNLIxhaeary8
s8PkllV9FlbSJ6lPV/24O0p0F/R+kTP1FF5oJO+qrX0XYdujktkj425OPqj/9Nzm
xHWEoLg7cBgGoHvmUzlpcNyR9qs2AWZGDMP1BPMkjkQlKFj0dxE4iCj/ZcDdHXpf
Z199rumsAhiVVcJFAgwt6S1FJkEp4ZhPy0WJqqTKMa0nZTevnXxu/q7LVy3fd8tT
tZXpgm06PN97f3uSu4DpGdXDFKkWWftINoYevxuVdO9Xx+hIRSrYS3SGqpPAwy6j
wWz2HjdkQgCbWHLs1Ll9F+auaAN+VjLbHkkAHKQf0RW53De1yCXGg6e8zCFJU1Nh
iXZgVp+yarg/+6o9mH/WzkqU4mOh6Y4AMDk2bdLgFg2b+HpH0rtPv8BaOum3zURr
ieCT739/hQGjU9BigqhWesrkbNpvniU3IrIPFyzIKLRwCuU+Q7WYC7/9o4Y7NuSb
m58mVAI7zJ1E2ynweq7dJV8YmvJhct/lbGzSpcxx/kZDjPTxg51uN0z8mSye68Z+
wqQKTulfxkd9cnFow4vuXJZ35wzUfxVZIOjUUqt6sprzfW2mtz2UYrt+QmeGpoRo
JXgPqzGnAFwcOkatf5SriN6Y3Sp7rtKmnXBHKny8xwiWDmnUDwBsUi/szZ6oyK8p
1EXq38bjWhie4lp12vTI
=ATIY
-----END PGP SIGNATURE-----

--Apple-Mail=_27376192-DBF9-4B8F-AE13-DD09B8DC7C35--


From nobody Tue Dec 15 18:49: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 C9D5A1A1B49 for ; Tue, 15 Dec 2015 18:48:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.266
X-Spam-Level: 
X-Spam-Status: No, score=-102.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epBycTidOp_p for ; Tue, 15 Dec 2015 18:48:57 -0800 (PST)
Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C83C1A1B3C for ; Tue, 15 Dec 2015 18:48:57 -0800 (PST)
Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.15.0.59/8.15.0.59) with SMTP id tBG2maFw008222; Tue, 15 Dec 2015 21:48:46 -0500
Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 1ytssh0ru9-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Dec 2015 21:48:46 -0500
Received: from STNTEXMB10.cis.neustar.com ([169.254.5.186]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Tue, 15 Dec 2015 21:48:45 -0500
From: "Peterson, Jon" 
To: Eric Burger , "modern@ietf.org" 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHRHl26JRlUivReh0qEPOxM4UAYr57FC3CAgABrkwCABZwMgIACTx4A//+HU4A=
Date: Wed, 16 Dec 2015 02:48:45 +0000
Message-ID: 
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com>  <566ED5E3.9020203@usdonovans.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.7.151005
x-originating-ip: [192.168.128.142]
Content-Type: multipart/alternative; boundary="_000_D2960FC717592Djonpetersonneustarbiz_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-12-16_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 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310007 definitions=main-1512160040
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 16 Dec 2015 02:48:59 -0000

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


I'd write a long mail explaining why I think the work here is important and=
 tractable, but then I'd lose my place in line for Star Wars. This isn't re=
ally the right time of year to scare up participant energy or consensus.

But seriously, I'm not going to argue the group isn't sleepy. Other than me=
, and Tom, and Chris, there hasn't been much editorial energy. And of cours=
e the people who think this group should not have been chartered in the fir=
st place will naturally fill that vacuum. We do need to find a way to breat=
he some life into this, maybe with an interim or something. Agreed that the=
re's no consensus for this expressed here now. But at some point, we will n=
eed a path to make a decision about adoption.

Jon Peterson
Neustar, Inc.

From: Modern > on b=
ehalf of Eric Burger >
Date: Tuesday, December 15, 2015 at 6:00 PM
To: "modern@ietf.org" >
Subject: Re: [Modern] Problem statement draft as working group document

Simple. In over six months, there have been precisely zero substantive mess=
ages on the MODERN list, save your message last month asking if the silence=
 means everyone thinks this is a good idea or if silence means no one cares=
.

I am glad to see my brief response just five days ago generated close to 10=
% of the total number of messages on the list since the list started, which=
 was close to six months before the work group was chartered. I.e., includi=
ng all of the charter discussion.

What response did my one word email elucidate? One person saying the docume=
nt should be adopted, one work group chair valiantly trying to say the docu=
ment should be adopted, and a ton of folks saying it should not be adopted.

We neither vote nor allow mob rule. However, given no one cared literally o=
ne peep for over six months and only one person thinks the document is read=
y to be a work group item, we are a long, long, long way from adopting the =
document.

You do have consensus, but it is not the consensus you are looking for.



On Dec 14, 2015, at 9:44 AM, Steve Donovan > wrote:

Eric,

Could you elaborate on why you think the document should not become a worki=
ng group item.
Thanks,

Steve

On 12/10/15 7:05 PM, Eric Burger wrote:

Nah. :-)



On Dec 10, 2015, at 1:40 PM, Steve Donovan  wrote:

There has been no response to this so I'm going to suggest we put a deadlin=
e on opinions.

Please express your opinion on making draft-peterson-modern-problems-02 a w=
orking group document before Thursday, December 17th.

It is important that anyone who supports the promotion of the document also=
 express their opinion.

Thanks,

Steve

On 11/13/15 3:53 PM, Steve Donovan wrote:


All,

During the IETF94 MODERN WG meeting there was consensus that draft-peterson=
-modern-problems-02 be accepted as a working group document.  This would be=
 to address the architecture Architecture Overview milestone.

It was recognized that it is not in final form but would be a good starting=
 point for the architecture overview.

Please comment on whether or not this should become a working group documen=
t.

Regards,

Steve

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

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



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

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


--_000_D2960FC717592Djonpetersonneustarbiz_
Content-Type: text/html; charset="us-ascii"
Content-ID: <9F2CFFAE2911684199DF576A379731A2@neustar.biz>
Content-Transfer-Encoding: quoted-printable












I'd write a long mail explaining why I think the work here is importan=
t and tractable, but then I'd lose my place in line for Star Wars. This isn=
't really the right time of year to scare up participant energy or consensu=
s.







But seriously, I'm not going to argue the group isn't sleepy. Other th=
an me, and Tom, and Chris, there hasn't been much editorial energy. And of =
course the people who think this group should not have been chartered in th=
e first place will naturally fill
 that vacuum. We do need to find a way to breathe some life into this, mayb=
e with an interim or something. Agreed that there's no consensus for this e=
xpressed here now. But at some point, we will need a path to make a decisio=
n about adoption.







Jon Peterson


Neustar, Inc.









From: Modern <modern-bounces@ietf.org> on behalf of Eric =
Burger <eburger@standardst=
rack.com>

Date: Tuesday, December 15, 2015 at=
 6:00 PM

To: "modern@ietf.org" <=
modern@ietf.org>

Subject: Re: [Modern] Problem state=
ment draft as working group document












Simple. In over six months, there have been precisely zero substantive mess=
ages on the MODERN list, save your message last month asking if the silence=
 means everyone thinks this is a good idea or if silence means no one cares=
. 






I am glad to see my brief response just five days ago gener=
ated close to 10% of the total number of messages on the list since the lis=
t started, which was close to six months before the work group was chartere=
d. I.e., including all of the charter
 discussion.







What response did my one word email elucidate? One person s=
aying the document should be adopted, one work group chair valiantly trying=
 to say the document should be adopted, and a ton of folks saying it should=
 not be adopted.







We neither vote nor allow mob rule. However, given no one c=
ared literally one peep for over six months and only one person thinks the =
document is ready to be a work group item, we are a long, long, long way fr=
om adopting the document.







You do have consensus, but it is not the consensus you are =
looking for.



















On Dec 14, 2015, at 9:44 AM, Steve Donovan <srdonovan@usdonovans.com>=
 wrote:






Eric,



Could you elaborate on why you think the document should not become a worki=
ng group item.





Thanks,



Steve




On 12/10/15 7:05 PM, Eric Burger wrote:






Nah. :-)






On Dec 10, 2015, at 1:40 PM, Steve Donovan <s=
rdonovan@usdonovans.com> wrote:

There has been no response to this so I'm going to suggest we put a deadlin=
e on opinions.

Please express your opinion on making draft-peterson-modern-problems-02 a w=
orking group document before Thursday, December 17th.

It is important that anyone who supports the promotion of the document also=
 express their opinion.

Thanks,

Steve

On 11/13/15 3:53 PM, Steve Donovan wrote:





All,

During the IETF94 MODERN WG meeting there was consensus that draft-peterson=
-modern-problems-02 be accepted as a working group document.  This would be=
 to address the architecture Architecture Overview milestone.

It was recognized that it is not in final form but would be a good starting=
 point for the architecture overview.

Please comment on whether or not this should become a working group documen=
t.

Regards,

Steve

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




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








 


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







_______________________________________________

Modern mailing list

Modern@ietf.org

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





















--_000_D2960FC717592Djonpetersonneustarbiz_--


From nobody Tue Dec 15 18:58:49 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9E81A1B89 for ; Tue, 15 Dec 2015 18:58:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.011
X-Spam-Level: 
X-Spam-Status: No, score=-1.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaJCuOKvqGAy for ; Tue, 15 Dec 2015 18:58:46 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF1341A1B57 for ; Tue, 15 Dec 2015 18:58:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=hzGURv8VI1kbqzeT+KhQUlb48J5m1kAs7N+chlF8VmA=;  b=sf/bbrJD5cCq55DsgZR2dvTVL7+LwfTDzbwWCpu2wuubcrhd9fFjVy473aN4zY/qxWH1w1D58KbemiqpZMAc6tkF3CbsbQaFx5weJo2cn4MkEygaj45Qu2Hq+1wzH0XimCHkymtdzE5CAvaqA767eDTjlXXoYqg5JcP7V55i6gc=;
Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:53110 helo=[192.168.15.111]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1a92If-0005Jz-2Q for modern@ietf.org; Tue, 15 Dec 2015 18:58:46 -0800
Content-Type: multipart/signed; boundary="Apple-Mail=_18EFE5F7-F127-4CE7-BCD3-82CF0BCF3D12"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
X-Pgp-Agent: GPGMail 2.6b2
From: Eric Burger 
In-Reply-To: 
Date: Tue, 15 Dec 2015 21:58:44 -0500
Message-Id: <37B69406-BE6E-4D8E-A955-00E41DBCB97F@standardstrack.com>
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com>  <566ED5E3.9020203@usdonovans.com>  
To: "modern@ietf.org" 
X-Mailer: Apple Mail (2.3112)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 16 Dec 2015 02:58:49 -0000

--Apple-Mail=_18EFE5F7-F127-4CE7-BCD3-82CF0BCF3D12
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_450807E3-2D6E-4B65-B22B-B45E0B6AFF65"


--Apple-Mail=_450807E3-2D6E-4B65-B22B-B45E0B6AFF65
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Happy New Year to all!

> On Dec 15, 2015, at 9:48 PM, Peterson, Jon  =
wrote:
>=20
>=20
> I'd write a long mail explaining why I think the work here is =
important and tractable, but then I'd lose my place in line for Star =
Wars. This isn't really the right time of year to scare up participant =
energy or consensus.
>=20
> But seriously, I'm not going to argue the group isn't sleepy. Other =
than me, and Tom, and Chris, there hasn't been much editorial energy. =
And of course the people who think this group should not have been =
chartered in the first place will naturally fill that vacuum. We do need =
to find a way to breathe some life into this, maybe with an interim or =
something. Agreed that there's no consensus for this expressed here now. =
But at some point, we will need a path to make a decision about =
adoption.
>=20
> Jon Peterson
> Neustar, Inc.
>=20
> From: Modern > on behalf of Eric Burger =
>
> Date: Tuesday, December 15, 2015 at 6:00 PM
> To: "modern@ietf.org " >
> Subject: Re: [Modern] Problem statement draft as working group =
document
>=20
> Simple. In over six months, there have been precisely zero substantive =
messages on the MODERN list, save your message last month asking if the =
silence means everyone thinks this is a good idea or if silence means no =
one cares.
>=20
> I am glad to see my brief response just five days ago generated close =
to 10% of the total number of messages on the list since the list =
started, which was close to six months before the work group was =
chartered. I.e., including all of the charter discussion.
>=20
> What response did my one word email elucidate? One person saying the =
document should be adopted, one work group chair valiantly trying to say =
the document should be adopted, and a ton of folks saying it should not =
be adopted.
>=20
> We neither vote nor allow mob rule. However, given no one cared =
literally one peep for over six months and only one person thinks the =
document is ready to be a work group item, we are a long, long, long way =
from adopting the document.
>=20
> You do have consensus, but it is not the consensus you are looking =
for.
>=20
>=20
>=20
>> On Dec 14, 2015, at 9:44 AM, Steve Donovan > wrote:
>>=20
>> Eric,
>>=20
>> Could you elaborate on why you think the document should not become a =
working group item.
>> Thanks,
>>=20
>> Steve
>>=20
>> On 12/10/15 7:05 PM, Eric Burger wrote:
>>> Nah. :-)
>>>=20
>>>> On Dec 10, 2015, at 1:40 PM, Steve Donovan =
  wrote:
>>>>=20
>>>> There has been no response to this so I'm going to suggest we put a =
deadline on opinions.
>>>>=20
>>>> Please express your opinion on making =
draft-peterson-modern-problems-02 a working group document before =
Thursday, December 17th.
>>>>=20
>>>> It is important that anyone who supports the promotion of the =
document also express their opinion.
>>>>=20
>>>> Thanks,
>>>>=20
>>>> Steve
>>>>=20
>>>> On 11/13/15 3:53 PM, Steve Donovan wrote:
>>>>> All,
>>>>>=20
>>>>> During the IETF94 MODERN WG meeting there was consensus that =
draft-peterson-modern-problems-02 be accepted as a working group =
document.  This would be to address the architecture Architecture =
Overview milestone.
>>>>>=20
>>>>> It was recognized that it is not in final form but would be a good =
starting point for the architecture overview.
>>>>>=20
>>>>> Please comment on whether or not this should become a working =
group document.
>>>>>=20
>>>>> Regards,
>>>>>=20
>>>>> Steve
>>>>>=20
>>>>> _______________________________________________
>>>>> Modern mailing list
>>>>> Modern@ietf.org =
https://www.ietf.org/mailman/listinfo/modern =
____________________________=
___________________
>>>> Modern mailing list
>>>> Modern@ietf.org =
https://www.ietf.org/mailman/listinfo/modern =

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

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

>=20


--Apple-Mail=_450807E3-2D6E-4B65-B22B-B45E0B6AFF65
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

Happy New Year to all!

On Dec 15, 2015, at 9:48 PM, Peterson, Jon <jon.peterson@neustar.biz> wrote:













I'd write a long mail explaining why I think the work here is important and tractable, but then I'd lose my place in line for Star Wars. This isn't really the right time of year to scare up participant energy or consensus.







But seriously, I'm not going to argue the group isn't sleepy. Other than me, and Tom, and Chris, there hasn't been much editorial energy. And of course the people who think this group should not have been chartered in the first place will naturally fill
 that vacuum. We do need to find a way to breathe some life into this, maybe with an interim or something. Agreed that there's no consensus for this expressed here now. But at some point, we will need a path to make a decision about adoption.







Jon Peterson


Neustar, Inc.









From: Modern <modern-bounces@ietf.org> on behalf of Eric Burger <eburger@standardstrack.com>

Date: Tuesday, December 15, 2015 at 6:00 PM

To: "modern@ietf.org" <modern@ietf.org>

Subject: Re: [Modern] Problem statement draft as working group document












Simple. In over six months, there have been precisely zero substantive messages on the MODERN list, save your message last month asking if the silence means everyone thinks this is a good idea or if silence means no one cares. 






I am glad to see my brief response just five days ago generated close to 10% of the total number of messages on the list since the list started, which was close to six months before the work group was chartered. I.e., including all of the charter
 discussion.







What response did my one word email elucidate? One person saying the document should be adopted, one work group chair valiantly trying to say the document should be adopted, and a ton of folks saying it should not be adopted.







We neither vote nor allow mob rule. However, given no one cared literally one peep for over six months and only one person thinks the document is ready to be a work group item, we are a long, long, long way from adopting the document.







You do have consensus, but it is not the consensus you are looking for.



















On Dec 14, 2015, at 9:44 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:






Eric,



Could you elaborate on why you think the document should not become a working group item.





Thanks,



Steve




On 12/10/15 7:05 PM, Eric Burger wrote:






Nah. :-)






On Dec 10, 2015, at 1:40 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:

There has been no response to this so I'm going to suggest we put a deadline on opinions.

Please express your opinion on making draft-peterson-modern-problems-02 a working group document before Thursday, December 17th.

It is important that anyone who supports the promotion of the document also express their opinion.

Thanks,

Steve

On 11/13/15 3:53 PM, Steve Donovan wrote:





All,

During the IETF94 MODERN WG meeting there was consensus that draft-peterson-modern-problems-02 be accepted as a working group document.  This would be to address the architecture Architecture Overview milestone.

It was recognized that it is not in final form but would be a good starting point for the architecture overview.

Please comment on whether or not this should become a working group document.

Regards,

Steve

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




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








 


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







_______________________________________________

Modern mailing list

Modern@ietf.org

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
























--Apple-Mail=_450807E3-2D6E-4B65-B22B-B45E0B6AFF65--

--Apple-Mail=_18EFE5F7-F127-4CE7-BCD3-82CF0BCF3D12
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

iQIcBAEBCAAGBQJWcNNkAAoJEORoZaSQsc1IUVUQAMmDVr+0e7TTHIiqi73oYhq0
wwl8HvrHoNhjyh0jb2YU5mwVmzmMR4WEtPx/Kirb1X7+n6fZXZ9a5UHNUh2l0vhO
OHeZ19syCjLxCNUtMAgUMPn73V9yMqTE5d/T+QjQ0z7gga9CBpOpsnaNcB6hc4VW
JJXiqqC/s67l/8vhfRSmzcR5ZBLB+frkZblR+qlcDMuBBKkKy49c0/ZlgUcQO3vj
swZ0oQLEeRpLR4phFjWbBQ7q46L02wuMfaNHqxcoWMt4Kyqy1xtG3b8CwTZnKm4/
4Nk3IG5Xo0yIR88sCkvQ8ltxj6JTOMK/kBy4fFnv7Bs2UMYigg3j7FowkZ8SkxMK
VYmrd08l6E3DhCMlTpMlwto41/zNwcCulbVHOKQWOa748kVYQSlKwfN8UTLGOQ+U
v8ne3NdM/v2ERxOuYA5QE5gkYHCFFDpznyO/yUPNYBFu5nAlhNFK1gSOMOJEES2t
jAs8+1nQXdQ3qEGbuHR6oorx2TCgHKKyWXOxCEGeCA+WlAysPYK1BTuYxz6a1XLe
aFwv23C0iViunw2g6rTbk3Yu+FjuUhpyzlZUDUnNC8JhMeWBVqjZinYV14HvKfnV
eaMz2KdvZG6wq04+MjOl4n+4jNK0xuihTQX3pyaIcg9kPwmkRQUPPk+iRiJCR/Yl
Sk8Tgm6GyweRhdiB8AJT
=6Wda
-----END PGP SIGNATURE-----

--Apple-Mail=_18EFE5F7-F127-4CE7-BCD3-82CF0BCF3D12--


From nobody Wed Dec 16 13:27:47 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E71C1A8A9C for ; Wed, 16 Dec 2015 13:27:45 -0800 (PST)
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 OuM40Egvqdlt for ; Wed, 16 Dec 2015 13:27:43 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BE331A89EB for ; Wed, 16 Dec 2015 13:27:43 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 9BEF820DDD for ; Wed, 16 Dec 2015 16:27:42 -0500 (EST)
Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Wed, 16 Dec 2015 16:27:42 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=45xRH7c2YUafs5KR4Mc9i5waTyY=; b=JPLaRu xoc67tK4/WuV/OWQ937ABQ9fwU79VqRgmszjiUIp9vCz+0Iiz184L9u4xp3Y35S+ RUxvnCK8eHXyKsp/34n+H+66ikrWj1PphJtXiDkiZ7nIa78CS9JY7ZmvlYEUeGaU XfY1MLbGF/Mt10gzwYazw7A+XpIYjiDk5zK1Y=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=45xRH7c2YUafs5K R4Mc9i5waTyY=; b=auVzX4Vko7m4DGnEzy2BQH94ST+TcfDTHNY4Yay9gTuKvuN VTCUwERl+vFPEBk6PY0fw4LifWlGmYe/thuR7lYoBUFK9ZxJO9c2kVY/U+3+6vaH 7x/RvAeAaucbpRCbPd7X5ZqYaebXHFOk4FSUmWSxNPj07YgVMeDNTweST+xQ=
X-Sasl-enc: M4LK8OvrSPMgSgcc9Q/lJAO04hNq8xto+14yXBTPnOvm 1450301262
Received: from dhcp-10-150-9-247.cisco.com (unknown [173.38.117.88]) by mail.messagingengine.com (Postfix) with ESMTPA id F1A14680110; Wed, 16 Dec 2015 16:27:41 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Alissa Cooper 
In-Reply-To: <6C827E0C-682C-4484-8F21-20A446746858@shockey.us>
Date: Wed, 16 Dec 2015 16:27:41 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <0F2A509D-5DEA-4416-BEEF-3D814C4D02E3@cooperw.in>
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com> <056701d136a3$e1c49120$a54db360$@ch> <566F1A34.9020402@nostrum.com> <6C827E0C-682C-4484-8F21-20A446746858@shockey.us>
To: Richard Shockey 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: modern@ietf.org, Steve Donovan , Richard Hill , Adam Roach 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 16 Dec 2015 21:27:45 -0000

Hi Richard,

> On Dec 14, 2015, at 7:02 PM, Richard Shockey  =
wrote:
>=20
>=20
>=20
> On 12/14/15, 2:36 PM, "Modern on behalf of Adam Roach" =
 wrote:
>=20
>> On 12/14/15 13:16, Richard Hill wrote:
>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Adam =
Roach
>>>=20
>>>> I think this document is a good starting point for outlining the =
basic
>>>> shape of the problem and the use cases MODERN is intended to =
address.
>>> Yes, but it seems to me to be placing the cart before the horse. The =
draft
>>> is outlining technical solutions for things that aren't, as far as I =
know,
>>> yet possible from a regulatory point of view.
>>=20
>> Where you see a cart and a horse, I see a chicken and an egg. Someone=20=

>> has to go first. If taken in the opposite order, your objection could=20=

>> easily be reversed to read "the proposed regulations are outlining=20
>> requirements for solutions that aren't, as far as I know, yet=20
>> technically possible."
>>=20
>> In any case, what we say on the topic in *this* forum is largely=20
>> academic, since it's not the WG participants or even the chairs that=20=

>> decide to start and end WGs. If you'd like to debate the existence of=20=

>> MODERN -- which seems to be your implied intent -- that's a broader=20=

>> conversation that you need to take up with the ADs and the IESG.
>=20
>=20
> RS> Adam our objections were NOT considered during the charter phase =
here.  This was the worst chartering process I=E2=80=99ve ever witnessed =
in the IETF. And I personally blame the IESG here for ignoring our =
concerns. And the sponsoring AD in particular..the record on that is =
clear.=20

I=E2=80=99m sorry that you feel that way. There was an extended amount =
of discussion about the charter with substantial revisions made in =
response to points raised by you and others. As per usual in the IETF, I =
think we landed in a place where no one got quite what they wanted.

This WG will be held to the same standard as all others. At chartering =
time, we had interest from multiple parties in seeing the chartered work =
through to completion, and we=E2=80=99ve seen some individual =
contributions in the meantime beyond the problem statement. But if =
motivation wanes and can=E2=80=99t be rekindled through efforts by the =
chairs and interested participants, we always have the option of closing =
the group.=20

Folks who object to the problem statement because they do not believe =
there is a problem here the IETF can solve have been heard, I think.=20

Alissa

>=20
>=20
>> I'll=20
>> note that the question of existence has already been asked and =
answered=20
>> based on earlier discussions, so you'll need to show up with =
previously=20
>> unmade arguments.
>>=20
>> But that conversation doesn't have bearing on whether this document =
is a=20
>> good match for the WG charter.
>=20
>=20
> RS> The conversation is this a proper WG item .. We say NO.=20



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


From nobody Wed Dec 16 14:41: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 2EC321A905F for ; Wed, 16 Dec 2015 14:41:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.58
X-Spam-Level: *
X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 DTklycxQTg77 for ; Wed, 16 Dec 2015 14:41:28 -0800 (PST)
Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) by ietfa.amsl.com (Postfix) with SMTP id 77ACF1A9059 for ; Wed, 16 Dec 2015 14:41:28 -0800 (PST)
Received: (qmail 30381 invoked by uid 0); 16 Dec 2015 22:41:28 -0000
Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy5.mail.unifiedlayer.com with SMTP; 16 Dec 2015 22:41:28 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with  id uNMF1r00X1MNPNq01NMJiV; Wed, 16 Dec 2015 15:21:27 -0700
X-Authority-Analysis: v=2.1 cv=Zc6OaKlA c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=0BRvPPsJEo4A:10 a=wUQvQvOEmiQA:10 a=jqBRFv0mrdUA:10 a=48vgC7mUAAAA:8 a=Z80JlwQ0AAAA:8 a=oL6L-EQFg_dMibEQKBcA:9 a=G9JoSbe4ZoXNpnSa:21 a=ik0lxhqGOEA7dWvG:21 a=QEXdDO2ut3YA: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=uyj9XM9CGbCDczfNi/qFiJKWvdTGMkdtDqKI7Gd1D+w=;  b=CQoRex30FAfZRwQjKOekKG9ZATytaqqZ1b2p3I/KPOL8l1enj86lKysMZqo5PhibmneH29m8yyvwZgS0wadiQCM9Tc/Kla0h7nlWWxOg0WfQTcntZ10ipkN+CnbbeZFg;
Received: from [50.241.241.5] (port=55710 helo=[172.20.2.220]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1a9KRg-0001sq-65; Wed, 16 Dec 2015 15:21:16 -0700
User-Agent: Microsoft-MacOutlook/0.0.0.151105
Date: Wed, 16 Dec 2015 17:21:06 -0500
From: Richard Shockey 
To: Alissa Cooper 
Message-ID: 
Thread-Topic: [Modern] Problem statement draft as working group document
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com> <056701d136a3$e1c49120$a54db360$@ch> <566F1A34.9020402@nostrum.com> <6C827E0C-682C-4484-8F21-20A446746858@shockey.us> <0F2A509D-5DEA-4416-BEEF-3D814C4D02E3@cooperw.in>
In-Reply-To: <0F2A509D-5DEA-4416-BEEF-3D814C4D02E3@cooperw.in>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 50.241.241.5 authed with richard+shockey.us}
Archived-At: 
Cc: modern@ietf.org, Steve Donovan , Richard Hill , Adam Roach 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 16 Dec 2015 22:41:32 -0000

>Hi Richard,
>
>> On Dec 14, 2015, at 7:02 PM, Richard Shockey  wrote:
>>=20
>>=20
>>=20
>> On 12/14/15, 2:36 PM, "Modern on behalf of Adam Roach"  wrote:
>>=20
>>> On 12/14/15 13:16, Richard Hill wrote:
>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Adam Roach
>>>>=20
>>>>> I think this document is a good starting point for outlining the basi=
c
>>>>> shape of the problem and the use cases MODERN is intended to address.
>>>> Yes, but it seems to me to be placing the cart before the horse. The d=
raft
>>>> is outlining technical solutions for things that aren't, as far as I k=
now,
>>>> yet possible from a regulatory point of view.
>>>=20
>>> Where you see a cart and a horse, I see a chicken and an egg. Someone=20
>>> has to go first. If taken in the opposite order, your objection could=20
>>> easily be reversed to read "the proposed regulations are outlining=20
>>> requirements for solutions that aren't, as far as I know, yet=20
>>> technically possible."
>>>=20
>>> In any case, what we say on the topic in *this* forum is largely=20
>>> academic, since it's not the WG participants or even the chairs that=20
>>> decide to start and end WGs. If you'd like to debate the existence of=20
>>> MODERN -- which seems to be your implied intent -- that's a broader=20
>>> conversation that you need to take up with the ADs and the IESG.
>>=20
>>=20
>> RS> Adam our objections were NOT considered during the charter phase her=
e.  This was the worst chartering process I=E2=80=99ve ever witnessed in the IETF.=
 And I personally blame the IESG here for ignoring our concerns. And the spo=
nsoring AD in particular..the record on that is clear.=20
>
>I=E2=80=99m sorry that you feel that way. There was an extended amount of discus=
sion about the charter with substantial revisions made in response to points=
 raised by you and others. As per usual in the IETF, I think we landed in a =
place where no one got quite what they wanted.



RS> Well we are going to have to disagree. This process has made a fair num=
ber of people  angry. The email record is quite clear that the legitimate co=
ncern of some of us about Charter/WG overreach was not considered or flatly =
ignored in the final decision to charter this work.  Its the worst charterin=
g excersise I=E2=80=99ve experienced in a long time. =20



>
>This WG will be held to the same standard as all others. At chartering tim=
e, we had interest from multiple parties in seeing the chartered work throug=
h to completion, and we=E2=80=99ve seen some individual contributions in the meant=
ime beyond the problem statement. But if motivation wanes and can=E2=80=99t be rek=
indled through efforts by the chairs and interested participants, we always =
have the option of closing the group.


RS> It serves no purpose to debate this further this year.  Peterson is rig=
ht, for once, =E2=80=A6 we should not disturb the needs of the many to get their S=
tar Wars tickets on time =20



>=20
>
>Folks who object to the problem statement because they do not believe ther=
e is a problem here the IETF can solve have been heard, I think.




RS> I=E2=80=99m afraid, once again you really don=E2=80=99t understand, =20

One, the charter is so overreaching as to be functionally useless. It viola=
tes every rational way the IETF works. Instead of choosing descrete definabl=
e problems and building on success it proports to nearly redefine the way th=
e telecom industry works and redesign how its numbering and addressing works=
.=20

Second, the concept of E.164 numbering administration is a sovereign respon=
sibility of nation states as we have no requirements from NRA=E2=80=99s on what th=
ere requirements actually are, or if they really care.   And is not clear th=
at that expertise is in the IETF.  Some of us have been to this Rodeo before=
 and it did not necessarily turn out well.  Oh and the gratuitous ENUM bashi=
ng gets old after a while.=20

Third.. The concept of highly distributed synchronized databases is in fact=
 useful. White Spaces proved that but the operational experience in that app=
lication is still thin. I echo Penn Pfautz comments something like this coul=
d, maybe, possibly, be useful, but certainly not for the number allocation a=
pplication the proposed problem statement. Right now that application is too=
 set in concrete. I do not know one NA based service provider that is prepar=
ed to look at something new for this.   There ARE examples of de novo metada=
ta for telephone numbers where this might be useful but a rational standardi=
zation strategy would not to define a protocol through the Open Standards pr=
ocess but engage in a Open Source project. Prove the solution via running co=
de FIRST and then consider standardizing the solution set=E2=80=A6

And some of us can=E2=80=99t afford to engage in the Internet Engineering Travel =
Club..tm  especially when the block is 300 rooms.

Same time next year.. Happy New Year  :-)  See you in Berlin=E2=80=A6 :-)    =20



>=20
>
>Alissa
>
>>=20
>>=20
>>> I'll=20
>>> note that the question of existence has already been asked and answered=
=20
>>> based on earlier discussions, so you'll need to show up with previously=
=20
>>> unmade arguments.
>>>=20
>>> But that conversation doesn't have bearing on whether this document is =
a=20
>>> good match for the WG charter.
>>=20
>>=20
>> RS> The conversation is this a proper WG item .. We say NO.=20
>
>
>
>>=20
>>=20
>>>=20
>>> /a
>>>=20
>>> _______________________________________________
>>> Modern mailing list
>>> Modern@ietf.org
>>> https://www.ietf.org/mailman/listinfo/modern
>>=20
>> _______________________________________________
>> Modern mailing list
>> Modern@ietf.org
>> https://www.ietf.org/mailman/listinfo/modern
>


From nobody Thu Dec 17 09:03:59 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633051B2FC3 for ; Thu, 17 Dec 2015 09:03:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.003
X-Spam-Level: 
X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id az5kpnRS9-1H for ; Thu, 17 Dec 2015 09:03:54 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0746.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:746]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B7E71B2FC2 for ; Thu, 17 Dec 2015 09:03:54 -0800 (PST)
Received: from BN1BFFO11FD042.protection.gbl (10.58.144.32) by BN1BFFO11HUB046.protection.gbl (10.58.144.193) with Microsoft SMTP Server (TLS) id 15.1.346.13; Thu, 17 Dec 2015 17:03:32 +0000
Authentication-Results: spf=pass (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; nostrum.com; dkim=none (message not signed) header.d=none;nostrum.com; dmarc=bestguesspass action=none header.from=sprint.com;
Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.38 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.38; helo=plsapdm2.corp.sprint.com;
Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BN1BFFO11FD042.mail.protection.outlook.com (10.58.144.105) with Microsoft SMTP Server (TLS) id 15.1.355.15 via Frontend Transport; Thu, 17 Dec 2015 17:03:32 +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 tBHGks2m029415;  Thu, 17 Dec 2015 11:03:32 -0600
Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by plsapdm2.corp.sprint.com with ESMTP id 1ytsewrvcq-2 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 17 Dec 2015 11:03:32 -0600
Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M07.ad.sprint.com (2002:90e2:801a::90e2:801a) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 17 Dec 2015 12:03:29 -0500
Received: from PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed]) by PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed%24]) with mapi id 15.00.1076.000; Thu, 17 Dec 2015 11:03:29 -0600
From: "Gorman, Pierce A [CTO]" 
To: Richard Shockey , Alissa Cooper 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHROEiYKCigIa6jakmAIZNM6lCGV57OlCAAgADTIpA=
Date: Thu, 17 Dec 2015 17:03:29 +0000
Message-ID: 
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com> <056701d136a3$e1c49120$a54db360$@ch> <566F1A34.9020402@nostrum.com> <6C827E0C-682C-4484-8F21-20A446746858@shockey.us> <0F2A509D-5DEA-4416-BEEF-3D814C4D02E3@cooperw.in> 
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.26]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD042; 1:bXlDqVzcFmnxBxz3zPNmfEDGJH5FRunhC+CvR5AVNL4lT6nIvp3zimUqAdN1a/+YjYhMLbtMIQe3fi+MMXGXm74XPF2/es8VMFqtsAatFDsnHwXjfQaGmj0WaQYyX80cdgCo9Idzer08w0KJ8ykE2d2kwLO8IErUiWI65lG68iGphCHzGAR3IVW5rsW7HGVVmiz1mboQUjqOKQ8OJYHVxks5dwbWja25R3thyeU0D7U0tNhYADOkc7WFIOi5NnRPXx0w2hbFZbWbAFyOAcQGS+wdYoTmgSpNPrRegAoWDFVNDuJvfVNhcT2Ei5ypO517qGuDaQFSUouxbX9woEjXlJIQNZGvtvXFOJJ/AF01zYweeV44KI90hiVPO+yYy1mz
X-Forefront-Antispam-Report: CIP:144.230.172.38; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(24454002)(13464003)(55674003)(377454003)(189002)(199003)(479174004)(97736004)(3846002)(102836003)(50986999)(81156007)(2900100001)(6116002)(92566002)(586003)(87936001)(5250100002)(47776003)(2950100001)(24736003)(6806005)(5008740100001)(1220700001)(11100500001)(5001770100001)(50466002)(54356999)(5004730100002)(15395725005)(108616004)(5003600100002)(5001960100002)(86362001)(106466001)(76176999)(15975445007)(189998001)(106116001)(93886004)(1096002)(19580405001)(23676002)(33646002)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB046; H:plsapdm2.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB046; 2:INalCcNQpB92vTkyq8jP1KTi5+6MHxl5m1fHDrUO/ZuaGq2fJqz81x31mZ+jMW9n6hpxeuNefCKMgPUOYXO6j14vZY0MkbppwIkfnTByMKAk8y09DWu31jOEBhTrBtuEDbxBt1uhxI4Izy375QQrig==; 3:a7gzCOOMB80NMIKUAS2H0zZg28NwF4uUFPjYZhmo5+GTvA9vOHZCijZVt83aZ6EGgIrSR2VAdyZZgw5V8EdU45rm1tF6znZUEK0vzGVjtjN9AJU9C3EH5hOHrPNEARqHaPBHevPjZzRFNSt+t6MZCd7sUkJ4Deo6rnF1yNR8gyRqRt0SejosFUmAT3Wsp5P1parL43BUXtNY5vj4I4WO741+DvQ23uSNwWecMJ9kLYb4XKIRRoFCEEpnWMSTIrgx8mxjvaAjgoYcJtL9uNVh4Q==; 25:UzQjf5Xv2fI9k/tdPKPdKKg0nSrWWvTrIVMlFJirewpx+YRtH7g3OONOFya3FLaIFhIaEOPUrW/b5q3ksNNB33iLfXm+7dPg5bS/iisiEuzBEzrkkrHrVSEHtwb72wUWy7dUIWHQrqG84Xwh7Rg9Y/EGbFUIdub/d3UHBGGme2vM+EOZi7w743nbSLZKSr41fIUd5KJRWaSNVe3RPRiigk4fgVisnXis7r84sDdcfuo3VdwInsri7fpVNulg2LmuUr9nwF4eWP9YHG+d7ybaYg==
X-Exchange-Antispam-Report-Test: UriScan:; BCL:0; PCL:0; RULEID:(8251501002);  SRVR:BN1BFFO11HUB046; UriScan:(18430343700868);
X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB046; 20:Y+w99KePGBf8EBWJxmsGnnydQy1ImLrsoFxlWGd4oDG307Qzs+3s6uF9gKfEhEHp5oSNjDq1SI0PlN7yrjXIeKavWJdROYXNm4ZfGv4y31nejnERQX1I9Cv2unAu3i8foDcbNyKapOyXKiK52zOm8aFpjA6ZrLEhCfLb81SCH7hb953cCmgMs3Zcy9VhxHKhkzSDTjVIZ7Vfgc/NU/WHJXE3eLoorDCJzatTuBpBHQ0YwBfzufBXt/bqJBnPLveK; 4:k28h5fn5NVT2tp8oShQucWLf118C9Cb+Qat2q27xrMSSuIanotBMHjXftET3to4esRsYvFo+nbwzbkpiB7vHC+di0r3ewfx2QTj+5eRa9sWz7ywKXGyeeedsrpZIb3pZOukpsFYXEzgnfTBQSIWO/RPKviI7ZQK//VBB7Q8gmozfbrq23hHc4ixg0qBVd8gglphA570VvFBmqRFaZoIZOI0SHw//ylxEwR/8w6P2oETUgChND5ebxzEQPnLA2PW9XkaMp07/WEwqTrswR1AiOdTSJrDDBMhYhtSgoy/8xtwShwtukTgwv4Ny7yPt8gxQXDVhrbfD1y0jwvqmlYWZB5G6rCMCTx9Af3Z69tSCweYL6k94V48Z/BWTLzKUb2Kkn3OxQ0mlEkuOCLxP8M4JW15dkvCfyzmbLwwb1QxulE1aVMOcCuhT1Msbuv0duNBO
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:BN1BFFO11HUB046; BCL:0; PCL:0; RULEID:; SRVR:BN1BFFO11HUB046; 
X-Forefront-PRVS: 07935ACF08
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjFCRkZPMTFIVUIwNDY7MjM6VmFRWkRjRUpZaHNYZnpqTktMSnVwd1ho?= =?utf-8?B?SkNyQTJOdXB2RDN6bitSc2puRnMvNnIrZUc0ZUFzcms2RlRrSXJ1OG5MblIy?= =?utf-8?B?V1krTkRzTUttc2IreG9ZUlltZDA3c2VlTnZIcUNXU2xDYm05YzhDUHozNlBo?= =?utf-8?B?UEYxbEl1YjJYK2s0Q25mQVUxdVpzTWlDcVdCa1NvZzJDMFlXckpaUjlnQ2ZM?= =?utf-8?B?MjBKQ3FBeWJVZlRocjBGZmVCczNQZGs0ZlZVN0pXa1pPYVpHOEwvQndZWERL?= =?utf-8?B?aHJOa0k1YUJKYkg0UEV0OSsrN2Z3VTZ3S2xYRVFVVWpYMjg3bGZpN1htcU9R?= =?utf-8?B?SW96bkRSOWlxOXFDblR6NW1qeEhhN2ppNkhqb2VhTjB4RmVndkNXTUFydU9Y?= =?utf-8?B?NUtObUhmRVJBUjgzWU02Q2taSHRYdVgrSjVFTTFXcUVTdEVza2N4ck4rbHBw?= =?utf-8?B?UE82WWV2SGFDRm5pWUc0WWFVUGowQ0F3R1Y5Z1BpZzZUWnRaQmh5TTl6WkRv?= =?utf-8?B?eS9rSjFrdktLNGJFS0daRWtmYzZtV21yK3pBNkVlTHgrb0t5UE9QS2xETDRj?= =?utf-8?B?K0FJN2YyUlEzUDVsSUdJQVhsbkdDbTFtaUZCdm1ad0I2YXJJUUY1bkZBZXpy?= =?utf-8?B?RGZqdWJrUmlWaTZGd0ZCMFc0VVA2ZEVjcmdIZ2pyMVZ1Zk94ZEFTQW9EVTcz?= =?utf-8?B?S1lrdlFQZmlvVmtBMlZRSngzVVdQN2NQWnh1RVJrYUE5U3pzNUZjRDZ6Tm84?= =?utf-8?B?aWlwcFRHaUN0Z3ZsdkFvZlc4VUNFb1JEcmtIYmZTQko3SUJEdW5WUVFjcllx?= =?utf-8?B?cHJjZkZaVDZtWko2MTJrY3VwZXd2elY5bGlWQ1RTcE41RWpxdnMxMXNjQjYx?= =?utf-8?B?QlB6WEd4cDd5eDk4c3VLekJkZnFQS25HN3NFMmczbWJzTnR6NVZDRDhRaDBM?= =?utf-8?B?OFBWcGJZSVVra2xJckUyM3l5ZlAxN3JKekM3RkF4R0NYV1MxYmdFMGFrTTBl?= =?utf-8?B?cGtVY3pBVmdieDBzZkdYZmdnNEVhbnJOVVl3bUhaYVJuT0UwZmpKbTg4ZDQx?= =?utf-8?B?RmFNb1lTc0h3dmFCSVNicnA3dktMNUpOTFpCVVF6N2JDai9rUmFTRyswZ2xU?= =?utf-8?B?ZWpnL3dZcjMwTlIwbXQ3bXhDNnRrVGpMSjNFYjI5VWRuQThxVjgwRXliQ3ZX?= =?utf-8?B?Q1NDWDY5OXNReVB4cllBSDRlMDN1bGVDaysxdC9lNVJqS29wOVhoaWdtc29x?= =?utf-8?B?L1UvQm1odVJWZUFNUlhoNmR6aFMvMGovNWc2aHJUd2NsTFI4UndYWmNHNjht?= =?utf-8?B?UXI1TTQ3OEF5U2l1d2J5VVhuZmg1QjExVE5UYldXMjcycUZKZDd4K3ZjZFIy?= =?utf-8?B?VjNhRExIRGcrbUViVjdySHlROERYdGRaUlFWdGhvNlg1MWQ0bFFxSEhHT1Fj?= =?utf-8?B?QkJsRDBDc1kvWjZJOGVXR2crSFBhSnFGQkJWZm1IQzhmWS9GbWpXZGZPSnY4?= =?utf-8?B?QTZUTVNrUVB2VSthOElUT0NXSGpPejQ0alJQYVBwaW1XOEZSVDJQL2RmR1Rt?= =?utf-8?B?NEMwRlYza3RrRjEyMG5jWmNibmwzWkdOZUI5aDlJSVdUNGdEdjNkcXd3d3Fm?= =?utf-8?B?T1lBclA5a3BPcG9UY2Z5aEoxZ3hqZzROVll0Nll4dUV1bDdla3NNdnkwUGt0?= =?utf-8?Q?bTUYUkqZngvIZ2rboR5Ch5eZ50aU3Izb44tdKfV7m?=
X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB046; 5:wctQQb7pdYya2miso1pz4zS5uVElAW4bVxkB0HDhQ5qSXUTBmaAVwBpWqMJugw7Tu5IkjSW+h0Z4oJQ0lPSqegbyrUATDEdWdpBLjamz+IEHoehRFr6wOxKUaMlLMi1TvfuwSs2S/W2dCLNh9DZ9UA==; 24:BJc5YAB3hgqwGru78hiiDAtBM0EmnUQ1IdIv7np8a9uvHoowYnCaySfa6htIYolBkto+rLvR3fb9S4/0ux4sFbizAGOerSmv/gxrLChQalE=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: sprint.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Dec 2015 17:03:32.6260 (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: BN1BFFO11HUB046
Archived-At: 
Cc: Steve Donovan , Richard Hill , "modern@ietf.org" , Adam Roach 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 17 Dec 2015 17:03:58 -0000

SSdtIGEgbmV3YmllIGF0IElFVEYgcHJvY2Vzc2VzLiAgSSd2ZSB0aG91Z2h0IG9mIFJGQ3MgYXMg
ZG9jdW1lbnRzIGludGVuZGVkIHRvIHNvbHZlIG5ldyBwcm9ibGVtcyBvciBvbGRlciBwcm9ibGVt
cyBidXQgaW4gc29tZSBiZXR0ZXIgbW9yZSB1c2VmdWwgd2F5IHRoZW4gd2FzIHBvc3NpYmxlIHdp
dGggZXhpc3Rpbmcgc3RhbmRhcmRzLg0KDQpNYW55IFJGQ3MgaGF2ZSBiZWVuIGlzc3VlZCB3aGlj
aCBuZXZlciBlbmpveWVkIGEgcmVhbC1saXZlIG1hdGVyaWFsIGltcGxlbWVudGF0aW9uLiAgSSd2
ZSBzb21ldGltZXMgd29uZGVyZWQgaWYgdGhlIGF1dGhvcnMgYW5kIGFkbWluaXN0cmF0b3JzIGhh
ZCBrbm93biBpbiBhZHZhbmNlIHRoYXQgdGhlaXIgZWZmb3J0cyB3b3VsZCBiZSBmcnVpdGxlc3Mg
KHBlcmhhcHMgZXZlbiBtb2NrZWQpLCB3b3VsZCB0aGV5IGhhdmUgcHVyc3VlZCB0aGUgZWZmb3J0
IGFueXdheT8NCg0KSSB0aGluayBJIGhhdmUgbXkgYW5zd2VyLg0KDQotLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KRnJvbTogTW9kZXJuIFttYWlsdG86bW9kZXJuLWJvdW5jZXNAaWV0Zi5vcmdd
IE9uIEJlaGFsZiBPZiBSaWNoYXJkIFNob2NrZXkNClNlbnQ6IERlY2VtYmVyIDE2LCAyMDE1IDQ6
MjEgUE0NClRvOiBBbGlzc2EgQ29vcGVyIDxhbGlzc2FAY29vcGVydy5pbj4NCkNjOiBtb2Rlcm5A
aWV0Zi5vcmc7IFN0ZXZlIERvbm92YW4gPHNyZG9ub3ZhbkB1c2Rvbm92YW5zLmNvbT47IFJpY2hh
cmQgSGlsbCA8cmhpbGxAaGlsbC1hLmNoPjsgQWRhbSBSb2FjaCA8YWRhbUBub3N0cnVtLmNvbT4N
ClN1YmplY3Q6IFJlOiBbTW9kZXJuXSBQcm9ibGVtIHN0YXRlbWVudCBkcmFmdCBhcyB3b3JraW5n
IGdyb3VwIGRvY3VtZW50DQoNCg0KPkhpIFJpY2hhcmQsDQo+DQo+PiBPbiBEZWMgMTQsIDIwMTUs
IGF0IDc6MDIgUE0sIFJpY2hhcmQgU2hvY2tleSA8cmljaGFyZEBzaG9ja2V5LnVzPiB3cm90ZToN
Cj4+DQo+Pg0KPj4NCj4+IE9uIDEyLzE0LzE1LCAyOjM2IFBNLCAiTW9kZXJuIG9uIGJlaGFsZiBv
ZiBBZGFtIFJvYWNoIiA8bW9kZXJuLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGFkYW1A
bm9zdHJ1bS5jb20+IHdyb3RlOg0KPj4NCj4+PiBPbiAxMi8xNC8xNSAxMzoxNiwgUmljaGFyZCBI
aWxsIHdyb3RlOg0KPj4+PiBGcm9tOiBNb2Rlcm4gW21haWx0bzptb2Rlcm4tYm91bmNlc0BpZXRm
Lm9yZ10gT24gQmVoYWxmIE9mIEFkYW0NCj4+Pj4gUm9hY2gNCj4+Pj4NCj4+Pj4+IEkgdGhpbmsg
dGhpcyBkb2N1bWVudCBpcyBhIGdvb2Qgc3RhcnRpbmcgcG9pbnQgZm9yIG91dGxpbmluZyB0aGUN
Cj4+Pj4+IGJhc2ljIHNoYXBlIG9mIHRoZSBwcm9ibGVtIGFuZCB0aGUgdXNlIGNhc2VzIE1PREVS
TiBpcyBpbnRlbmRlZCB0byBhZGRyZXNzLg0KPj4+PiBZZXMsIGJ1dCBpdCBzZWVtcyB0byBtZSB0
byBiZSBwbGFjaW5nIHRoZSBjYXJ0IGJlZm9yZSB0aGUgaG9yc2UuDQo+Pj4+IFRoZSBkcmFmdCBp
cyBvdXRsaW5pbmcgdGVjaG5pY2FsIHNvbHV0aW9ucyBmb3IgdGhpbmdzIHRoYXQgYXJlbid0LA0K
Pj4+PiBhcyBmYXIgYXMgSSBrbm93LCB5ZXQgcG9zc2libGUgZnJvbSBhIHJlZ3VsYXRvcnkgcG9p
bnQgb2Ygdmlldy4NCj4+Pg0KPj4+IFdoZXJlIHlvdSBzZWUgYSBjYXJ0IGFuZCBhIGhvcnNlLCBJ
IHNlZSBhIGNoaWNrZW4gYW5kIGFuIGVnZy4NCj4+PiBTb21lb25lIGhhcyB0byBnbyBmaXJzdC4g
SWYgdGFrZW4gaW4gdGhlIG9wcG9zaXRlIG9yZGVyLCB5b3VyDQo+Pj4gb2JqZWN0aW9uIGNvdWxk
IGVhc2lseSBiZSByZXZlcnNlZCB0byByZWFkICJ0aGUgcHJvcG9zZWQgcmVndWxhdGlvbnMNCj4+
PiBhcmUgb3V0bGluaW5nIHJlcXVpcmVtZW50cyBmb3Igc29sdXRpb25zIHRoYXQgYXJlbid0LCBh
cyBmYXIgYXMgSQ0KPj4+IGtub3csIHlldCB0ZWNobmljYWxseSBwb3NzaWJsZS4iDQo+Pj4NCj4+
PiBJbiBhbnkgY2FzZSwgd2hhdCB3ZSBzYXkgb24gdGhlIHRvcGljIGluICp0aGlzKiBmb3J1bSBp
cyBsYXJnZWx5DQo+Pj4gYWNhZGVtaWMsIHNpbmNlIGl0J3Mgbm90IHRoZSBXRyBwYXJ0aWNpcGFu
dHMgb3IgZXZlbiB0aGUgY2hhaXJzIHRoYXQNCj4+PiBkZWNpZGUgdG8gc3RhcnQgYW5kIGVuZCBX
R3MuIElmIHlvdSdkIGxpa2UgdG8gZGViYXRlIHRoZSBleGlzdGVuY2UNCj4+PiBvZiBNT0RFUk4g
LS0gd2hpY2ggc2VlbXMgdG8gYmUgeW91ciBpbXBsaWVkIGludGVudCAtLSB0aGF0J3MgYQ0KPj4+
IGJyb2FkZXIgY29udmVyc2F0aW9uIHRoYXQgeW91IG5lZWQgdG8gdGFrZSB1cCB3aXRoIHRoZSBB
RHMgYW5kIHRoZSBJRVNHLg0KPj4NCj4+DQo+PiBSUz4gQWRhbSBvdXIgb2JqZWN0aW9ucyB3ZXJl
IE5PVCBjb25zaWRlcmVkIGR1cmluZyB0aGUgY2hhcnRlciBwaGFzZSBoZXJlLiAgVGhpcyB3YXMg
dGhlIHdvcnN0IGNoYXJ0ZXJpbmcgcHJvY2VzcyBJ4oCZdmUgZXZlciB3aXRuZXNzZWQgaW4gdGhl
IElFVEYuIEFuZCBJIHBlcnNvbmFsbHkgYmxhbWUgdGhlIElFU0cgaGVyZSBmb3IgaWdub3Jpbmcg
b3VyIGNvbmNlcm5zLiBBbmQgdGhlIHNwb25zb3JpbmcgQUQgaW4gcGFydGljdWxhci4udGhlIHJl
Y29yZCBvbiB0aGF0IGlzIGNsZWFyLg0KPg0KPknigJltIHNvcnJ5IHRoYXQgeW91IGZlZWwgdGhh
dCB3YXkuIFRoZXJlIHdhcyBhbiBleHRlbmRlZCBhbW91bnQgb2YgZGlzY3Vzc2lvbiBhYm91dCB0
aGUgY2hhcnRlciB3aXRoIHN1YnN0YW50aWFsIHJldmlzaW9ucyBtYWRlIGluIHJlc3BvbnNlIHRv
IHBvaW50cyByYWlzZWQgYnkgeW91IGFuZCBvdGhlcnMuIEFzIHBlciB1c3VhbCBpbiB0aGUgSUVU
RiwgSSB0aGluayB3ZSBsYW5kZWQgaW4gYSBwbGFjZSB3aGVyZSBubyBvbmUgZ290IHF1aXRlIHdo
YXQgdGhleSB3YW50ZWQuDQoNCg0KDQpSUz4gV2VsbCB3ZSBhcmUgZ29pbmcgdG8gaGF2ZSB0byBk
aXNhZ3JlZS4gVGhpcyBwcm9jZXNzIGhhcyBtYWRlIGEgZmFpciBudW1iZXIgb2YgcGVvcGxlICBh
bmdyeS4gVGhlIGVtYWlsIHJlY29yZCBpcyBxdWl0ZSBjbGVhciB0aGF0IHRoZSBsZWdpdGltYXRl
IGNvbmNlcm4gb2Ygc29tZSBvZiB1cyBhYm91dCBDaGFydGVyL1dHIG92ZXJyZWFjaCB3YXMgbm90
IGNvbnNpZGVyZWQgb3IgZmxhdGx5IGlnbm9yZWQgaW4gdGhlIGZpbmFsIGRlY2lzaW9uIHRvIGNo
YXJ0ZXIgdGhpcyB3b3JrLiAgSXRzIHRoZSB3b3JzdCBjaGFydGVyaW5nIGV4Y2Vyc2lzZSBJ4oCZ
dmUgZXhwZXJpZW5jZWQgaW4gYSBsb25nIHRpbWUuDQoNCg0KDQo+DQo+VGhpcyBXRyB3aWxsIGJl
IGhlbGQgdG8gdGhlIHNhbWUgc3RhbmRhcmQgYXMgYWxsIG90aGVycy4gQXQgY2hhcnRlcmluZyB0
aW1lLCB3ZSBoYWQgaW50ZXJlc3QgZnJvbSBtdWx0aXBsZSBwYXJ0aWVzIGluIHNlZWluZyB0aGUg
Y2hhcnRlcmVkIHdvcmsgdGhyb3VnaCB0byBjb21wbGV0aW9uLCBhbmQgd2XigJl2ZSBzZWVuIHNv
bWUgaW5kaXZpZHVhbCBjb250cmlidXRpb25zIGluIHRoZSBtZWFudGltZSBiZXlvbmQgdGhlIHBy
b2JsZW0gc3RhdGVtZW50LiBCdXQgaWYgbW90aXZhdGlvbiB3YW5lcyBhbmQgY2Fu4oCZdCBiZSBy
ZWtpbmRsZWQgdGhyb3VnaCBlZmZvcnRzIGJ5IHRoZSBjaGFpcnMgYW5kIGludGVyZXN0ZWQgcGFy
dGljaXBhbnRzLCB3ZSBhbHdheXMgaGF2ZSB0aGUgb3B0aW9uIG9mIGNsb3NpbmcgdGhlIGdyb3Vw
Lg0KDQoNClJTPiBJdCBzZXJ2ZXMgbm8gcHVycG9zZSB0byBkZWJhdGUgdGhpcyBmdXJ0aGVyIHRo
aXMgeWVhci4gIFBldGVyc29uIGlzDQpSUz4gcmlnaHQsIGZvciBvbmNlLCDigKYgd2Ugc2hvdWxk
IG5vdCBkaXN0dXJiIHRoZSBuZWVkcyBvZiB0aGUgbWFueSB0bw0KUlM+IGdldCB0aGVpciBTdGFy
IFdhcnMgdGlja2V0cyBvbiB0aW1lDQoNCg0KDQo+DQo+DQo+Rm9sa3Mgd2hvIG9iamVjdCB0byB0
aGUgcHJvYmxlbSBzdGF0ZW1lbnQgYmVjYXVzZSB0aGV5IGRvIG5vdCBiZWxpZXZlIHRoZXJlIGlz
IGEgcHJvYmxlbSBoZXJlIHRoZSBJRVRGIGNhbiBzb2x2ZSBoYXZlIGJlZW4gaGVhcmQsIEkgdGhp
bmsuDQoNCg0KDQoNClJTPiBJ4oCZbSBhZnJhaWQsIG9uY2UgYWdhaW4geW91IHJlYWxseSBkb27i
gJl0IHVuZGVyc3RhbmQsDQoNCk9uZSwgdGhlIGNoYXJ0ZXIgaXMgc28gb3ZlcnJlYWNoaW5nIGFz
IHRvIGJlIGZ1bmN0aW9uYWxseSB1c2VsZXNzLiBJdCB2aW9sYXRlcyBldmVyeSByYXRpb25hbCB3
YXkgdGhlIElFVEYgd29ya3MuIEluc3RlYWQgb2YgY2hvb3NpbmcgZGVzY3JldGUgZGVmaW5hYmxl
IHByb2JsZW1zIGFuZCBidWlsZGluZyBvbiBzdWNjZXNzIGl0IHByb3BvcnRzIHRvIG5lYXJseSBy
ZWRlZmluZSB0aGUgd2F5IHRoZSB0ZWxlY29tIGluZHVzdHJ5IHdvcmtzIGFuZCByZWRlc2lnbiBo
b3cgaXRzIG51bWJlcmluZyBhbmQgYWRkcmVzc2luZyB3b3Jrcy4NCg0KU2Vjb25kLCB0aGUgY29u
Y2VwdCBvZiBFLjE2NCBudW1iZXJpbmcgYWRtaW5pc3RyYXRpb24gaXMgYSBzb3ZlcmVpZ24gcmVz
cG9uc2liaWxpdHkgb2YgbmF0aW9uIHN0YXRlcyBhcyB3ZSBoYXZlIG5vIHJlcXVpcmVtZW50cyBm
cm9tIE5SQeKAmXMgb24gd2hhdCB0aGVyZSByZXF1aXJlbWVudHMgYWN0dWFsbHkgYXJlLCBvciBp
ZiB0aGV5IHJlYWxseSBjYXJlLiAgIEFuZCBpcyBub3QgY2xlYXIgdGhhdCB0aGF0IGV4cGVydGlz
ZSBpcyBpbiB0aGUgSUVURi4gIFNvbWUgb2YgdXMgaGF2ZSBiZWVuIHRvIHRoaXMgUm9kZW8gYmVm
b3JlIGFuZCBpdCBkaWQgbm90IG5lY2Vzc2FyaWx5IHR1cm4gb3V0IHdlbGwuICBPaCBhbmQgdGhl
IGdyYXR1aXRvdXMgRU5VTSBiYXNoaW5nIGdldHMgb2xkIGFmdGVyIGEgd2hpbGUuDQoNClRoaXJk
Li4gVGhlIGNvbmNlcHQgb2YgaGlnaGx5IGRpc3RyaWJ1dGVkIHN5bmNocm9uaXplZCBkYXRhYmFz
ZXMgaXMgaW4gZmFjdCB1c2VmdWwuIFdoaXRlIFNwYWNlcyBwcm92ZWQgdGhhdCBidXQgdGhlIG9w
ZXJhdGlvbmFsIGV4cGVyaWVuY2UgaW4gdGhhdCBhcHBsaWNhdGlvbiBpcyBzdGlsbCB0aGluLiBJ
IGVjaG8gUGVubiBQZmF1dHogY29tbWVudHMgc29tZXRoaW5nIGxpa2UgdGhpcyBjb3VsZCwgbWF5
YmUsIHBvc3NpYmx5LCBiZSB1c2VmdWwsIGJ1dCBjZXJ0YWlubHkgbm90IGZvciB0aGUgbnVtYmVy
IGFsbG9jYXRpb24gYXBwbGljYXRpb24gdGhlIHByb3Bvc2VkIHByb2JsZW0gc3RhdGVtZW50LiBS
aWdodCBub3cgdGhhdCBhcHBsaWNhdGlvbiBpcyB0b28gc2V0IGluIGNvbmNyZXRlLiBJIGRvIG5v
dCBrbm93IG9uZSBOQSBiYXNlZCBzZXJ2aWNlIHByb3ZpZGVyIHRoYXQgaXMgcHJlcGFyZWQgdG8g
bG9vayBhdCBzb21ldGhpbmcgbmV3IGZvciB0aGlzLiAgIFRoZXJlIEFSRSBleGFtcGxlcyBvZiBk
ZSBub3ZvIG1ldGFkYXRhIGZvciB0ZWxlcGhvbmUgbnVtYmVycyB3aGVyZSB0aGlzIG1pZ2h0IGJl
IHVzZWZ1bCBidXQgYSByYXRpb25hbCBzdGFuZGFyZGl6YXRpb24gc3RyYXRlZ3kgd291bGQgbm90
IHRvIGRlZmluZSBhIHByb3RvY29sIHRocm91Z2ggdGhlIE9wZW4gU3RhbmRhcmRzIHByb2Nlc3Mg
YnV0IGVuZ2FnZSBpbiBhIE9wZW4gU291cmNlIHByb2plY3QuIFByb3ZlIHRoZSBzb2x1dGlvbiB2
aWEgcnVubmluZyBjb2RlIEZJUlNUIGFuZCB0aGVuIGNvbnNpZGVyIHN0YW5kYXJkaXppbmcgdGhl
IHNvbHV0aW9uIHNldOKApg0KDQpBbmQgc29tZSBvZiB1cyBjYW7igJl0IGFmZm9yZCB0byBlbmdh
Z2UgaW4gdGhlIEludGVybmV0IEVuZ2luZWVyaW5nIFRyYXZlbCBDbHViLi50bSAgZXNwZWNpYWxs
eSB3aGVuIHRoZSBibG9jayBpcyAzMDAgcm9vbXMuDQoNClNhbWUgdGltZSBuZXh0IHllYXIuLiBI
YXBweSBOZXcgWWVhciAgOi0pICBTZWUgeW91IGluIEJlcmxpbuKApiA6LSkNCg0KDQoNCj4NCj4N
Cj5BbGlzc2ENCj4NCj4+DQo+Pg0KPj4+IEknbGwNCj4+PiBub3RlIHRoYXQgdGhlIHF1ZXN0aW9u
IG9mIGV4aXN0ZW5jZSBoYXMgYWxyZWFkeSBiZWVuIGFza2VkIGFuZA0KPj4+IGFuc3dlcmVkIGJh
c2VkIG9uIGVhcmxpZXIgZGlzY3Vzc2lvbnMsIHNvIHlvdSdsbCBuZWVkIHRvIHNob3cgdXANCj4+
PiB3aXRoIHByZXZpb3VzbHkgdW5tYWRlIGFyZ3VtZW50cy4NCj4+Pg0KPj4+IEJ1dCB0aGF0IGNv
bnZlcnNhdGlvbiBkb2Vzbid0IGhhdmUgYmVhcmluZyBvbiB3aGV0aGVyIHRoaXMgZG9jdW1lbnQN
Cj4+PiBpcyBhIGdvb2QgbWF0Y2ggZm9yIHRoZSBXRyBjaGFydGVyLg0KPj4NCj4+DQo+PiBSUz4g
VGhlIGNvbnZlcnNhdGlvbiBpcyB0aGlzIGEgcHJvcGVyIFdHIGl0ZW0gLi4gV2Ugc2F5IE5PLg0K
Pg0KPg0KPg0KPj4NCj4+DQo+Pj4NCj4+PiAvYQ0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBNb2Rlcm4gbWFpbGluZyBsaXN0DQo+
Pj4gTW9kZXJuQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9tb2Rlcm4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KPj4gTW9kZXJuIG1haWxpbmcgbGlzdA0KPj4gTW9kZXJuQGlldGYub3JnDQo+
PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21vZGVybg0KPg0KDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTW9kZXJuIG1haWxp
bmcgbGlzdA0KTW9kZXJuQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL21vZGVybg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU3dpdGNo
IHRvIFNwcmludCBhbmQgc2F2ZSA1MCUgb24gVmVyaXpvbiwgQVQmVCBvciBULU1vYmlsZSByYXRl
cy4gWW91ciBzYXZpbmdzIGFyZSBndWFyYW50ZWVkIHVudGlsIDIwMTghIEF2YWlsYWJsZSBvbiBt
b3N0IHBsYW5zLiBMaW1pdGVkIHRpbWUgb2ZmZXIuIEV4Y2x1c2lvbnMgYW5kIHJlc3RyaWN0aW9u
cyBhcHBseS4gU2VlIHNwcmludC5jb20vc2F2ZTUwPGh0dHA6Ly9zcHJpbnQuY29tLzUwb2ZmPiBm
b3IgZGV0YWlscy4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVGhpcyBl
LW1haWwgbWF5IGNvbnRhaW4gU3ByaW50IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uIGludGVuZGVk
IGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIHJlY2lwaWVudChzKS4gQW55IHVzZSBieSBvdGhlcnMg
aXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxl
YXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhlIG1lc3Nh
Z2UuDQo=


From nobody Thu Dec 17 09:14:59 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1CC91A1ABE for ; Thu, 17 Dec 2015 09:14:57 -0800 (PST)
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 s92gRvhhFqsI for ; Thu, 17 Dec 2015 09:14:57 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E39291A039A for ; Thu, 17 Dec 2015 09:14:56 -0800 (PST)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tBHHEmNM071566 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 17 Dec 2015 11:14:49 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
To: "Gorman, Pierce A [CTO]" , Richard Shockey , Alissa Cooper 
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com> <056701d136a3$e1c49120$a54db360$@ch> <566F1A34.9020402@nostrum.com> <6C827E0C-682C-4484-8F21-20A446746858@shockey.us> <0F2A509D-5DEA-4416-BEEF-3D814C4D02E3@cooperw.in>  
From: Adam Roach 
Message-ID: <5672ED88.3090106@nostrum.com>
Date: Thu, 17 Dec 2015 11:14:48 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: Steve Donovan , Richard Hill , "modern@ietf.org" 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 17 Dec 2015 17:14:58 -0000

On 12/17/15 11:03, Gorman, Pierce A [CTO] wrote:
> Many RFCs have been issued which never enjoyed a real-live material implementation.  I've sometimes wondered if the authors and administrators had known in advance that their efforts would be fruitless (perhaps even mocked), would they have pursued the effort anyway?
>
> I think I have my answer.

If you don't think the work MODERN is doing will produce useful output, 
then I encourage you to find other ways to spend your time than trying 
to stop work. If your analysis is correct, the impact on you or anything 
you care about is approximately zero.

/a


From nobody Thu Dec 17 09:17:40 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A70211B2FCE for ; Thu, 17 Dec 2015 09:17:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 jh57v9aJskjW for ; Thu, 17 Dec 2015 09:17:34 -0800 (PST)
Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (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 B56851B2F0F for ; Thu, 17 Dec 2015 09:17:33 -0800 (PST)
Received: by mail-qg0-x229.google.com with SMTP id v36so12362104qgd.2 for ; Thu, 17 Dec 2015 09:17:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=E1x6Lkb2GF/F542+S70qSrrDMfADD4Ip1ibu3d99dZE=; b=c3DDOhAe9ZokdPOBB31pUmvMk5xOvI4qTOdvFZkQe37eViVjqcu1JZBKM0mU6PSCI7 pAaKTxYR1bsWfa0KuYSm1GGoYsKud3DvwIjsHeQGctycpm8bgD7t6KcMXVHr8IaT/mHw Cd6+3tRS/Uy7KjBHNF3AT6vjmHi/1qSz+hwtO07l9txKQMksgv0pNL7//HrU0B9fldI6 wnlvX75QsSN5W+zn8sD+8CIN5NWzhZB6gIhfO4EmUfbm19bcB0EkHCTzoAOc7RIMe+Qj 4Tgf+BPTomlGX6jhfnyBBAv4AXUlzFz2LK4LWnhjQrcpJttM9JGYjGBAW1jSRDOLIXIi RkGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=E1x6Lkb2GF/F542+S70qSrrDMfADD4Ip1ibu3d99dZE=; b=SUSEq1wKhb9njfW07QJ9QsUVdpgc4rqm2Km0RkTbp58z8QAFCuYJBM+pnLlWhZlO4z UHyfCB/yfSk9mUJ/Gy50GFl+d2ig/ofc+Ki1R7gy8Kk+DkNlvQnPCIJejx2mYo4hovgP fEMttqLClyW8WPxESgQcsbPXSa2SLm5EILxJtNo3D04pr0AiXi00M4U6ec7h7WJr87S/ L8tNMu8yysvYuWIq0yMBz02i7AKjf7QNK9AmC83AVexhs6BSA6OOjInRbETUkqa/4F0k 6orC1TYWWOFTFFff4vZkruP6xPkk84rEIIjU6KvkjwYYxGzDMmgqigsPD/ldt4XMN4gs KwEg==
X-Gm-Message-State: ALoCoQmeY64tqIZic/bLUjvidYEkVXaZqri0RR40GDUNZVnAMlIvCASDL2vnZf6mmnqe4QOOJvcJDtOaqtCArxqrpXiXU1FZzQ==
X-Received: by 10.140.248.197 with SMTP id t188mr4743442qhc.79.1450372652796;  Thu, 17 Dec 2015 09:17:32 -0800 (PST)
Received: from [10.33.192.14] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id h19sm5048829qgd.37.2015.12.17.09.17.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 17 Dec 2015 09:17:31 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_96DE4E43-7A74-4C4C-A611-474960EFC63B"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Brian Rosen 
In-Reply-To: 
Date: Thu, 17 Dec 2015 12:17:28 -0500
Message-Id: <62D8976B-8132-4C80-9656-6A3BD6853EE8@brianrosen.net>
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com> <056701d136a3$e1c49120$a54db360$@ch> <566F1A34.9020402@nostrum.com> <6C827E0C-682C-4484-8F21-20A446746858@shockey.us> <0F2A509D-5DEA-4416-BEEF-3D814C4D02E3@cooperw.in>  
To: "Gorman, Pierce A [CTO]" 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: Steve Donovan , Adam Roach , Alissa Cooper , "modern@ietf.org" , Richard Shockey , Richard Hill 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 17 Dec 2015 17:17:38 -0000

--Apple-Mail=_96DE4E43-7A74-4C4C-A611-474960EFC63B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

It happens.

It also happens that there is great skepticism that some new work will =
in fact actually be deployed, and yet it does get deployed, so I =
wouldn=E2=80=99t take your observation too far.

One of the great truisms of IETF, among other standards organizations is =
that it=E2=80=99s really hard to stop work where there is a sufficiently =
large group of people interested in pursuing, as long as it falls within =
the expertise of the organization.  That=E2=80=99s what is happening =
here.  It doesn=E2=80=99t matter that there is a large (even larger) =
group of people who want the work stopped.

There are enough of us who believe this work is important, will be =
implemented, and will likely supplant current ways of doing things.  You =
may not, that=E2=80=99s your privilege.  But we=E2=80=99re going to do =
the work.  It may be a waste of time.  We=E2=80=99re willing to take =
that chance.

Brian

> On Dec 17, 2015, at 12:03 PM, Gorman, Pierce A [CTO] =
 wrote:
>=20
> I'm a newbie at IETF processes.  I've thought of RFCs as documents =
intended to solve new problems or older problems but in some better more =
useful way then was possible with existing standards.
>=20
> Many RFCs have been issued which never enjoyed a real-live material =
implementation.  I've sometimes wondered if the authors and =
administrators had known in advance that their efforts would be =
fruitless (perhaps even mocked), would they have pursued the effort =
anyway?
>=20
> I think I have my answer.
>=20
> -----Original Message-----
> From: Modern [mailto:modern-bounces@ietf.org =
] On Behalf Of Richard Shockey
> Sent: December 16, 2015 4:21 PM
> To: Alissa Cooper >
> Cc: modern@ietf.org ; Steve Donovan =
>; Richard =
Hill >; Adam Roach =
>
> Subject: Re: [Modern] Problem statement draft as working group =
document
>=20
>=20
>> Hi Richard,
>>=20
>>> On Dec 14, 2015, at 7:02 PM, Richard Shockey  =
wrote:
>>>=20
>>>=20
>>>=20
>>> On 12/14/15, 2:36 PM, "Modern on behalf of Adam Roach" =
 wrote:
>>>=20
>>>> On 12/14/15 13:16, Richard Hill wrote:
>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Adam
>>>>> Roach
>>>>>=20
>>>>>> I think this document is a good starting point for outlining the
>>>>>> basic shape of the problem and the use cases MODERN is intended =
to address.
>>>>> Yes, but it seems to me to be placing the cart before the horse.
>>>>> The draft is outlining technical solutions for things that aren't,
>>>>> as far as I know, yet possible from a regulatory point of view.
>>>>=20
>>>> Where you see a cart and a horse, I see a chicken and an egg.
>>>> Someone has to go first. If taken in the opposite order, your
>>>> objection could easily be reversed to read "the proposed =
regulations
>>>> are outlining requirements for solutions that aren't, as far as I
>>>> know, yet technically possible."
>>>>=20
>>>> In any case, what we say on the topic in *this* forum is largely
>>>> academic, since it's not the WG participants or even the chairs =
that
>>>> decide to start and end WGs. If you'd like to debate the existence
>>>> of MODERN -- which seems to be your implied intent -- that's a
>>>> broader conversation that you need to take up with the ADs and the =
IESG.
>>>=20
>>>=20
>>> RS> Adam our objections were NOT considered during the charter phase =
here.  This was the worst chartering process I=E2=80=99ve ever witnessed =
in the IETF. And I personally blame the IESG here for ignoring our =
concerns. And the sponsoring AD in particular..the record on that is =
clear.
>>=20
>> I=E2=80=99m sorry that you feel that way. There was an extended =
amount of discussion about the charter with substantial revisions made =
in response to points raised by you and others. As per usual in the =
IETF, I think we landed in a place where no one got quite what they =
wanted.
>=20
>=20
>=20
> RS> Well we are going to have to disagree. This process has made a =
fair number of people  angry. The email record is quite clear that the =
legitimate concern of some of us about Charter/WG overreach was not =
considered or flatly ignored in the final decision to charter this work. =
 Its the worst chartering excersise I=E2=80=99ve experienced in a long =
time.
>=20
>=20
>=20
>>=20
>> This WG will be held to the same standard as all others. At =
chartering time, we had interest from multiple parties in seeing the =
chartered work through to completion, and we=E2=80=99ve seen some =
individual contributions in the meantime beyond the problem statement. =
But if motivation wanes and can=E2=80=99t be rekindled through efforts =
by the chairs and interested participants, we always have the option of =
closing the group.
>=20
>=20
> RS> It serves no purpose to debate this further this year.  Peterson =
is
> RS> right, for once, =E2=80=A6 we should not disturb the needs of the =
many to
> RS> get their Star Wars tickets on time
>=20
>=20
>=20
>>=20
>>=20
>> Folks who object to the problem statement because they do not believe =
there is a problem here the IETF can solve have been heard, I think.
>=20
>=20
>=20
>=20
> RS> I=E2=80=99m afraid, once again you really don=E2=80=99t =
understand,
>=20
> One, the charter is so overreaching as to be functionally useless. It =
violates every rational way the IETF works. Instead of choosing descrete =
definable problems and building on success it proports to nearly =
redefine the way the telecom industry works and redesign how its =
numbering and addressing works.
>=20
> Second, the concept of E.164 numbering administration is a sovereign =
responsibility of nation states as we have no requirements from NRA=E2=80=99=
s on what there requirements actually are, or if they really care.   And =
is not clear that that expertise is in the IETF.  Some of us have been =
to this Rodeo before and it did not necessarily turn out well.  Oh and =
the gratuitous ENUM bashing gets old after a while.
>=20
> Third.. The concept of highly distributed synchronized databases is in =
fact useful. White Spaces proved that but the operational experience in =
that application is still thin. I echo Penn Pfautz comments something =
like this could, maybe, possibly, be useful, but certainly not for the =
number allocation application the proposed problem statement. Right now =
that application is too set in concrete. I do not know one NA based =
service provider that is prepared to look at something new for this.   =
There ARE examples of de novo metadata for telephone numbers where this =
might be useful but a rational standardization strategy would not to =
define a protocol through the Open Standards process but engage in a =
Open Source project. Prove the solution via running code FIRST and then =
consider standardizing the solution set=E2=80=A6
>=20
> And some of us can=E2=80=99t afford to engage in the Internet =
Engineering Travel Club..tm  especially when the block is 300 rooms.
>=20
> Same time next year.. Happy New Year  :-)  See you in Berlin=E2=80=A6 =
:-)
>=20
>=20
>=20
>>=20
>>=20
>> Alissa
>>=20
>>>=20
>>>=20
>>>> I'll
>>>> note that the question of existence has already been asked and
>>>> answered based on earlier discussions, so you'll need to show up
>>>> with previously unmade arguments.
>>>>=20
>>>> But that conversation doesn't have bearing on whether this document
>>>> is a good match for the WG charter.
>>>=20
>>>=20
>>> RS> The conversation is this a proper WG item .. We say NO.
>>=20
>>=20
>>=20
>>>=20
>>>=20
>>>>=20
>>>> /a
>>>>=20
>>>> _______________________________________________
>>>> Modern mailing list
>>>> Modern@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/modern
>>>=20
>>> _______________________________________________
>>> Modern mailing list
>>> Modern@ietf.org
>>> https://www.ietf.org/mailman/listinfo/modern
>>=20
>=20
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern
>=20
> ________________________________
> Switch to Sprint and save 50% on Verizon, AT&T or T-Mobile rates. Your =
savings are guaranteed until 2018! Available on most plans. Limited time =
offer. Exclusions and restrictions apply. See sprint.com/save50 =
> for details.
>=20
> ________________________________
>=20
> This e-mail may contain Sprint proprietary information intended for =
the sole use of the recipient(s). Any use by others is prohibited. If =
you are not the intended recipient, please contact the sender and delete =
all copies of the message.
> _______________________________________________
> Modern mailing list
> Modern@ietf.org 
> https://www.ietf.org/mailman/listinfo/modern =


--Apple-Mail=_96DE4E43-7A74-4C4C-A611-474960EFC63B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

It happens.

It also happens that there is great skepticism that some new =
work will in fact actually be deployed, and yet it does get deployed, so =
I wouldn=E2=80=99t take your observation too far.
One of the great truisms of IETF, =
among other standards organizations is that it=E2=80=99s really hard to =
stop work where there is a sufficiently large group of people interested =
in pursuing, as long as it falls within the expertise of the =
organization.  That=E2=80=99s what is happening here.  It =
doesn=E2=80=99t matter that there is a large (even larger) group of =
people who want the work stopped.

There are enough of us who believe this =
work is important, will be implemented, and will likely supplant current =
ways of doing things.  You may not, that=E2=80=99s your privilege. =
 But we=E2=80=99re going to do the work.  It may be a waste of =
time.  We=E2=80=99re willing to take that chance.

Brian

On Dec 17, 2015, at 12:03 PM, Gorman, Pierce A [CTO] <Pierce.Gorman@sprint.com> wrote:

I'm a newbie at IETF processes.  I've =
thought of RFCs as documents intended to solve new problems or older =
problems but in some better more useful way then was possible with =
existing standards.

Many RFCs have been issued =
which never enjoyed a real-live material implementation.  I've =
sometimes wondered if the authors and administrators had known in =
advance that their efforts would be fruitless (perhaps even mocked), =
would they have pursued the effort anyway?

I think I have my answer.

-----Original Message-----
From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard =
Shockey
Sent: December 16, 2015 4:21 PM
To: Alissa Cooper =
<alissa@cooperw.in>
Cc: modern@ietf.org; Steve Donovan <srdonovan@usdonovans.com>; Richard Hill =
<rhill@hill-a.ch>; Adam Roach <adam@nostrum.com>
Subject: Re: [Modern] =
Problem statement draft as working group document


Hi =
Richard,

On Dec 14, 2015, at 7:02 PM, Richard Shockey <richard@shockey.us> =
wrote:



On =
12/14/15, 2:36 PM, "Modern on behalf of Adam Roach" <modern-bounces@ietf.org on behalf of adam@nostrum.com> =
wrote:

On 12/14/15 13:16, Richard Hill wrote:
From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Adam
Roach

I think this document is a good starting point for outlining =
the
basic shape of the problem and the use cases MODERN is =
intended to address.
Yes, but it seems to me =
to be placing the cart before the horse.
The draft is =
outlining technical solutions for things that aren't,
as =
far as I know, yet possible from a regulatory point of view.

Where you see a cart and a horse, =
I see a chicken and an egg.
Someone has to go first. If =
taken in the opposite order, your
objection could easily =
be reversed to read "the proposed regulations
are =
outlining requirements for solutions that aren't, as far as I
know, yet technically possible."

In any case, what we say on the topic in *this* forum is =
largely
academic, since it's not the WG participants or =
even the chairs that
decide to start and end WGs. If you'd =
like to debate the existence
of MODERN -- which seems to =
be your implied intent -- that's a
broader conversation =
that you need to take up with the ADs and the IESG.


RS> Adam our =
objections were NOT considered during the charter phase here.  This =
was the worst chartering process I=E2=80=99ve ever witnessed in the =
IETF. And I personally blame the IESG here for ignoring our concerns. =
And the sponsoring AD in particular..the record on that is clear.

I=E2=80=99m sorry that you feel =
that way. There was an extended amount of discussion about the charter =
with substantial revisions made in response to points raised by you and =
others. As per usual in the IETF, I think we landed in a place where no =
one got quite what they wanted.



RS> Well we are going to have to disagree. =
This process has made a fair number of people  angry. The email =
record is quite clear that the legitimate concern of some of us about =
Charter/WG overreach was not considered or flatly ignored in the final =
decision to charter this work.  Its the worst chartering excersise =
I=E2=80=99ve experienced in a long time.




This WG will be held to the same standard as all others. At =
chartering time, we had interest from multiple parties in seeing the =
chartered work through to completion, and we=E2=80=99ve seen some =
individual contributions in the meantime beyond the problem statement. =
But if motivation wanes and can=E2=80=99t be rekindled through efforts =
by the chairs and interested participants, we always have the option of =
closing the group.


RS> It serves no purpose to debate this =
further this year.  Peterson is
RS> right, for once, =E2=80=A6 we =
should not disturb the needs of the many to
RS> get their Star Wars =
tickets on time





Folks who object to the problem statement =
because they do not believe there is a problem here the IETF can solve =
have been heard, I think.




RS> I=E2=80=99m afraid, =
once again you really don=E2=80=99t understand,

One, the charter is so overreaching as to =
be functionally useless. It violates every rational way the IETF works. =
Instead of choosing descrete definable problems and building on success =
it proports to nearly redefine the way the telecom industry works and =
redesign how its numbering and addressing works.

Second, the concept of E.164 numbering =
administration is a sovereign responsibility of nation states as we have =
no requirements from NRA=E2=80=99s on what there requirements actually =
are, or if they really care.   And is not clear that that =
expertise is in the IETF.  Some of us have been to this Rodeo =
before and it did not necessarily turn out well.  Oh and the =
gratuitous ENUM bashing gets old after a while.

Third.. The concept of highly distributed =
synchronized databases is in fact useful. White Spaces proved that but =
the operational experience in that application is still thin. I echo =
Penn Pfautz comments something like this could, maybe, possibly, be =
useful, but certainly not for the number allocation application the =
proposed problem statement. Right now that application is too set in =
concrete. I do not know one NA based service provider that is prepared =
to look at something new for this.   There ARE examples of de =
novo metadata for telephone numbers where this might be useful but a =
rational standardization strategy would not to define a protocol through =
the Open Standards process but engage in a Open Source project. Prove =
the solution via running code FIRST and then consider standardizing the =
solution set=E2=80=A6

And some of us can=E2=80=99t=
 afford to engage in the Internet Engineering Travel Club..tm =
 especially when the block is 300 rooms.

Same time next year.. Happy New Year =
 :-)  See you in Berlin=E2=80=A6 :-)





Alissa



I'll
note that the question of existence has =
already been asked and
answered based on earlier =
discussions, so you'll need to show up
with previously =
unmade arguments.

But that conversation =
doesn't have bearing on whether this document
is a good =
match for the WG charter.


RS> The conversation is this a proper WG item .. We say =
NO.






/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

________________________________
Switch to Sprint and save =
50% on Verizon, AT&T or T-Mobile rates. Your savings are guaranteed =
until 2018! Available on most plans. Limited time offer. Exclusions and =
restrictions apply. See sprint.com/save50<http://sprint.com/50off> for =
details.

________________________________

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

=

--Apple-Mail=_96DE4E43-7A74-4C4C-A611-474960EFC63B--


From nobody Thu Dec 17 09:26: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 8F4FB1B2FEE for ; Thu, 17 Dec 2015 09:26:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rn209bIm6kcY for ; Thu, 17 Dec 2015 09:26:31 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 0F70C1B2FED for ; Thu, 17 Dec 2015 09:26:31 -0800 (PST)
Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id tBHHOWlX021210; Thu, 17 Dec 2015 12:26:26 -0500
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049295.ppops.net-00191d01. with ESMTP id 1ytsjfjt2e-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);  Thu, 17 Dec 2015 12:26:25 -0500
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 tBHHQOIF021463; Thu, 17 Dec 2015 12:26:24 -0500
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 tBHHQEl4021253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 17 Dec 2015 12:26:17 -0500
Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Thu, 17 Dec 2015 17:26:06 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.78]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0248.002; Thu, 17 Dec 2015 12:26:05 -0500
From: "DOLLY, MARTIN C" 
To: Adam Roach 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHROEiYt9tG2eQFXECnCpoLN3xbKp7OlCAAgADTIpCAAFjbAP//r1br
Date: Thu, 17 Dec 2015 17:26:05 +0000
Message-ID: 
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com> <056701d136a3$e1c49120$a54db360$@ch> <566F1A34.9020402@nostrum.com> <6C827E0C-682C-4484-8F21-20A446746858@shockey.us> <0F2A509D-5DEA-4416-BEEF-3D814C4D02E3@cooperw.in>  , <5672ED88.3090106@nostrum.com>
In-Reply-To: <5672ED88.3090106@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-12-17_02:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310007 definitions=main-1512170285
Archived-At: 
Cc: Steve Donovan , Alissa Cooper , "modern@ietf.org" , Richard Shockey , "Gorman, Pierce A \[CTO\]" , Richard Hill 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 17 Dec 2015 17:26:32 -0000

Adam

There are practical aspects of Modern, but a lot of theory too.  Be honest.=
=20

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards=20
AT&T
Cell: 609-903-3360
Email: md3135@att.com

> On Dec 17, 2015, at 12:15 PM, Adam Roach  wrote:
>=20
>> On 12/17/15 11:03, Gorman, Pierce A [CTO] wrote:
>> Many RFCs have been issued which never enjoyed a real-live material impl=
ementation.  I've sometimes wondered if the authors and administrators had =
known in advance that their efforts would be fruitless (perhaps even mocked=
), would they have pursued the effort anyway?
>>=20
>> I think I have my answer.
>=20
> If you don't think the work MODERN is doing will produce useful output, t=
hen I encourage you to find other ways to spend your time than trying to st=
op work. If your analysis is correct, the impact on you or anything you car=
e about is approximately zero.
>=20
> /a
>=20
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern


From nobody Thu Dec 17 10:02:34 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93DD91B301E for ; Thu, 17 Dec 2015 10:02:28 -0800 (PST)
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 7Ku-2wPJIjoN for ; Thu, 17 Dec 2015 10:02:19 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF271B301A for ; Thu, 17 Dec 2015 10:02:18 -0800 (PST)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tBHI2C2S075597 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 17 Dec 2015 12:02:12 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
To: Richard Shockey , Alissa Cooper 
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com> <056701d136a3$e1c49120$a54db360$@ch> <566F1A34.9020402@nostrum.com> <6C827E0C-682C-4484-8F21-20A446746858@shockey.us> <0F2A509D-5DEA-4416-BEEF-3D814C4D02E3@cooperw.in> 
From: Adam Roach 
Message-ID: <5672F8A3.4010101@nostrum.com>
Date: Thu, 17 Dec 2015 12:02:11 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: Steve Donovan , Richard Hill , modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 17 Dec 2015 18:02:28 -0000

On 12/16/15 16:21, Richard Shockey wrote:
> Well we are going to have to disagree. This process has made a fair number of people  angry. The email record is quite clear that the legitimate concern of some of us about Charter/WG overreach was not considered or flatly ignored in the final decision to charter this work.  Its the worst chartering excersise I’ve experienced in a long time.

If you believed these assertions in earnest, there was a well-known way 
to deal with it; see BCP 9, section 6.5 (and its subsections). I use the 
past tense because your objection is to the chartering of the MODERN WG, 
which puts you pretty well outside the two-month appeals window. I 
suspect that makes effectively no difference, because I think you'd have 
a remarkably hard time putting together a set of facts that that the 
IESG or IAB would find compelling.

At this point, how things proceed are in the purview of the WG chairs 
and the responsible AD. The chairs have attempted to steer you towards 
productive participation, which you actively declined (cf. "You can 
certainly hope"), and the responsible AD has weighed in with an 
indication that the IESG has heard, considered, and acted upon the 
objections you mention.

Sometimes us old-timers lose track of the process here, or possibly even 
forget that these things have been formalized. In this case, the 
applicable processes are described in BCPs 9, 25, and 83. I encourage 
you to take some time over the holidays to review all three. Take 
careful note that BCP 25 consists of two concatenated RFCs, the second 
of which you may find particularly interesting.

I look forward to your positive contributions -- or, if you can't find 
it in yourself to be useful, benign non-participation -- in the new year.

/a


From nobody Thu Dec 17 10:08:59 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA7F1B3016 for ; Thu, 17 Dec 2015 10:08:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjSGodv7eOrU for ; Thu, 17 Dec 2015 10:08:57 -0800 (PST)
Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A333B1B3018 for ; Thu, 17 Dec 2015 10:08:56 -0800 (PST)
Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBHI8liD019466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 17 Dec 2015 19:08:47 +0100
Received: from RHillNew (adsl-178-38-52-133.adslplus.ch [178.38.52.133]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBHI7q2c011092; Thu, 17 Dec 2015 19:07:52 +0100
From: "Richard Hill" 
To: "'Brian Rosen'" , "'Gorman, Pierce A [CTO]'" 
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com> <056701d136a3$e1c49120$a54db360$@ch> <566F1A34.9020402@nostrum.com> <6C827E0C-682C-4484-8F21-20A446746858@shockey.us> <0F2A509D-5DEA-4416-BEEF-3D814C4D02E3@cooperw.in>   <62D8976B-8132-4C80-9656-6A3BD6853EE8@brianrosen.net>
In-Reply-To: <62D8976B-8132-4C80-9656-6A3BD6853EE8@brianrosen.net>
Date: Thu, 17 Dec 2015 19:07:53 +0100
Message-ID: <007c01d138f5$db461040$91d230c0$@ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdE47tP2xCFINB4zTLSdGwOSizcmYAABpRNQ
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, 'Steve Donovan' , 'Alissa Cooper' , 'Adam Roach' , 'Richard Shockey' 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 17 Dec 2015 18:08:59 -0000

Please see embedded comment below.

Thanks and best,
Richard

>From: Brian Rosen [mailto:br@brianrosen.net]=20
>Sent: Thursday, December 17, 2015 18:17
>To: Gorman, Pierce A [CTO]
>Cc: Richard Shockey; Alissa Cooper; Steve Donovan; Richard Hill; =
modern@ietf.org; Adam Roach
>Subject: Re: [Modern] Problem statement draft as working group document
>

SNIP

>One of the great truisms of IETF, among other standards organizations =
is that it=E2=80=99s really hard
> to stop work where there is a sufficiently large group of people =
interested in pursuing,
> as long as it falls within the expertise of the organization. =20

Can you (or somebody else) explain to me how processes (which might have =
regulatory implications) regarding assignment of E.164 numbers fall =
within the expertise of the IETF?

Or have I misunderstood the scope of the work of this group?

SNIP=20


From nobody Thu Dec 17 10:12:15 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3841B3023 for ; Thu, 17 Dec 2015 10:12:14 -0800 (PST)
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 4PcrAHXqsE_e for ; Thu, 17 Dec 2015 10:12:13 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D825E1B3022 for ; Thu, 17 Dec 2015 10:12:13 -0800 (PST)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tBHICC5b076449 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 17 Dec 2015 12:12:12 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
To: Richard Hill , "'Brian Rosen'" , "'Gorman, Pierce A [CTO]'" 
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com> <056701d136a3$e1c49120$a54db360$@ch> <566F1A34.9020402@nostrum.com> <6C827E0C-682C-4484-8F21-20A446746858@shockey.us> <0F2A509D-5DEA-4416-BEEF-3D814C4D02E3@cooperw.in>   <62D8976B-8132-4C80-9656-6A3BD6853EE8@brianrosen.net> <007c01d138f5$db461040$91d230c0$@ch>
From: Adam Roach 
Message-ID: <5672FAFB.2060802@nostrum.com>
Date: Thu, 17 Dec 2015 12:12:11 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <007c01d138f5$db461040$91d230c0$@ch>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: modern@ietf.org, 'Steve Donovan' , 'Alissa Cooper' , 'Richard Shockey' 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 17 Dec 2015 18:12:14 -0000

On 12/17/15 12:07, Richard Hill wrote:
> Can you (or somebody else) explain to me how processes (which might have regulatory implications) regarding assignment of E.164 numbers fall within the expertise of the IETF?
>
> Or have I misunderstood the scope of the work of this group?

You have misunderstood the scope of the entire IETF. We design network 
protocols. We are not part of any regulatory bodies. What those bodies 
choose to do is entirely in their purview.

/a


From nobody Thu Dec 17 10:18: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 219AA1B300B for ; Thu, 17 Dec 2015 10:17:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.665
X-Spam-Level: 
X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPo4uL3CVBH3 for ; Thu, 17 Dec 2015 10:17:52 -0800 (PST)
Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id F031B1B2C0F for ; Thu, 17 Dec 2015 10:17:51 -0800 (PST)
Received: (qmail 6471 invoked by uid 0); 17 Dec 2015 18:17:48 -0000
Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy2.mail.unifiedlayer.com with SMTP; 17 Dec 2015 18:17:48 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with  id uhxc1r00a1MNPNq01hxfVH; Thu, 17 Dec 2015 10:57:47 -0700
X-Authority-Analysis: v=2.1 cv=Zc6OaKlA c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=0BRvPPsJEo4A:10 a=wUQvQvOEmiQA:10 a=jqBRFv0mrdUA:10 a=PeFO9FbFhS32YxYntvkA:9 a=HLLxP2VMAAAA:8 a=izV7ms69AAAA:8 a=yakATiurAAAA:8 a=48vgC7mUAAAA:8 a=Z80JlwQ0AAAA:8 a=zqk-QFPo6YCTVxtANXkA:9 a=5DGjb8Jg21mrpqG2:21 a=UMRpHWsnI3rZoOtX:21 a=QEXdDO2ut3YA:10 a=H_e1NcmSpxRWk5EtOTYA:9 a=Fs5iUmLe2wmeRyhH:21 a=g924NCxF_zB-dPO_:21 a=S3_b6tjmYN1vFvwF: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=Ed+NFCOOwG28Y97F0S4TAE38Ydpx6T8F9/QUFmiPMWU=;  b=Ipt3bwIESCKDyjVloX5Wi/zbnus0+XDpyggHFCITRwmk3mBN4x7oXfTTyot5u0kunm07nlrXZ8BH7tJ6sXRRv+6c3OabCreGyZYvTxu+fJAlxLmlpPWJxwi2oR0BlGY1;
Received: from [50.241.241.5] (port=36771 helo=[172.20.2.220]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1a9co3-00011z-N9; Thu, 17 Dec 2015 10:57:37 -0700
User-Agent: Microsoft-MacOutlook/0.0.0.151105
Date: Thu, 17 Dec 2015 12:57:25 -0500
From: Richard Shockey 
To: Brian Rosen , "Gorman, Pierce A [CTO]" 
Message-ID: <7082DBCA-ABC9-4DFD-90EC-32C5EEEE078C@shockey.us>
Thread-Topic: [Modern] Problem statement draft as working group document
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com> <056701d136a3$e1c49120$a54db360$@ch> <566F1A34.9020402@nostrum.com> <6C827E0C-682C-4484-8F21-20A446746858@shockey.us> <0F2A509D-5DEA-4416-BEEF-3D814C4D02E3@cooperw.in>   <62D8976B-8132-4C80-9656-6A3BD6853EE8@brianrosen.net>
In-Reply-To: <62D8976B-8132-4C80-9656-6A3BD6853EE8@brianrosen.net>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3533201855_847884571"
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 50.241.241.5 authed with richard+shockey.us}
Archived-At: 
Cc: "modern@ietf.org" , Steve Donovan , Richard Hill , Alissa Cooper , Adam Roach 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 17 Dec 2015 18:17:59 -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_3533201855_847884571
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


From:  Brian Rosen 
Date:  Thursday, December 17, 2015 at 12:17 PM
To:  "Pierce.Gorman@sprint.com" 
Cc:  Richard Shockey , Alissa Cooper , Steve Donovan , Richard Hill ,=
 "modern@ietf.org" , Adam Roach 
Subject:  Re: [Modern] Problem statement draft as working group document

It happens.

It also happens that there is great skepticism that some new work will in f=
act actually be deployed, and yet it does get deployed, so I wouldn=E2=80=99t take=
 your observation too far.

One of the great truisms of IETF, among other standards organizations is th=
at it=E2=80=99s really hard to stop work where there is a sufficiently large group=
 of people interested in pursuing, as long as it falls within the expertise =
of the organization. =20

RS> Which some of us dispute. I really really believe that E.164 numbering =
allocation is not within the Expertise of the IETF. =20


That=E2=80=99s what is happening here.  It doesn=E2=80=99t matter that there is a large=
 (even larger) group of people who want the work stopped.

RS>  Yes it does matter.  That is not what I was taught consensus was.  May=
be Donald Trump=E2=80=99s idea of consensus. =20
"My way or the highway.=E2=80=9D =20
=E2=80=9CMy protocol =E2=80=A6right or wrong!!=E2=80=9D
=E2=80=9CLets make the IETF great again! =E2=80=9C   sorry couldn=E2=80=99t resist that one.=20


There are enough of us who believe this work is important, will be implemen=
ted, and will likely supplant current ways of doing things.=20

RS> So what is actually your agenda here? If your agenda is really to overt=
hrow the existing national E.164 numbering administration model then just sa=
y so.=20

 =E2=80=9CWe think the FCC, CRTC, OFCOM etc guys are are a bunch of ."   =E2=80=9CThe E.164 Liberation Front=E2=80=9D  There is a T-Shirt for you.=20


 You may not, that=E2=80=99s your privilege.  But we=E2=80=99re going to do the work.  =
It may be a waste of time.  We=E2=80=99re willing to take that chance.

Brian

On Dec 17, 2015, at 12:03 PM, Gorman, Pierce A [CTO]  wrote:

I'm a newbie at IETF processes.  I've thought of RFCs as documents intended=
 to solve new problems or older problems but in some better more useful way =
then was possible with existing standards.

Many RFCs have been issued which never enjoyed a real-live material impleme=
ntation.  I've sometimes wondered if the authors and administrators had know=
n in advance that their efforts would be fruitless (perhaps even mocked), wo=
uld they have pursued the effort anyway?

I think I have my answer.

-----Original Message-----
From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard Shockey
Sent: December 16, 2015 4:21 PM
To: Alissa Cooper 
Cc: modern@ietf.org; Steve Donovan ; Richard Hill=
 ; Adam Roach 
Subject: Re: [Modern] Problem statement draft as working group document


Hi Richard,

On Dec 14, 2015, at 7:02 PM, Richard Shockey  wrote:



On 12/14/15, 2:36 PM, "Modern on behalf of Adam Roach"  wrote:

On 12/14/15 13:16, Richard Hill wrote:
From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Adam
Roach

I think this document is a good starting point for outlining the
basic shape of the problem and the use cases MODERN is intended to address.
Yes, but it seems to me to be placing the cart before the horse.
The draft is outlining technical solutions for things that aren't,
as far as I know, yet possible from a regulatory point of view.

Where you see a cart and a horse, I see a chicken and an egg.
Someone has to go first. If taken in the opposite order, your
objection could easily be reversed to read "the proposed regulations
are outlining requirements for solutions that aren't, as far as I
know, yet technically possible."

In any case, what we say on the topic in *this* forum is largely
academic, since it's not the WG participants or even the chairs that
decide to start and end WGs. If you'd like to debate the existence
of MODERN -- which seems to be your implied intent -- that's a
broader conversation that you need to take up with the ADs and the IESG.


RS> Adam our objections were NOT considered during the charter phase here. =
 This was the worst chartering process I=E2=80=99ve ever witnessed in the IETF. An=
d I personally blame the IESG here for ignoring our concerns. And the sponso=
ring AD in particular..the record on that is clear.

I=E2=80=99m sorry that you feel that way. There was an extended amount of discuss=
ion about the charter with substantial revisions made in response to points =
raised by you and others. As per usual in the IETF, I think we landed in a p=
lace where no one got quite what they wanted.



RS> Well we are going to have to disagree. This process has made a fair num=
ber of people  angry. The email record is quite clear that the legitimate co=
ncern of some of us about Charter/WG overreach was not considered or flatly =
ignored in the final decision to charter this work.  Its the worst charterin=
g excersise I=E2=80=99ve experienced in a long time.




This WG will be held to the same standard as all others. At chartering time=
, we had interest from multiple parties in seeing the chartered work through=
 to completion, and we=E2=80=99ve seen some individual contributions in the meanti=
me beyond the problem statement. But if motivation wanes and can=E2=80=99t be reki=
ndled through efforts by the chairs and interested participants, we always h=
ave the option of closing the group.


RS> It serves no purpose to debate this further this year.  Peterson is
RS> right, for once, =E2=80=A6 we should not disturb the needs of the many to
RS> get their Star Wars tickets on time





Folks who object to the problem statement because they do not believe there=
 is a problem here the IETF can solve have been heard, I think.




RS> I=E2=80=99m afraid, once again you really don=E2=80=99t understand,

One, the charter is so overreaching as to be functionally useless. It viola=
tes every rational way the IETF works. Instead of choosing descrete definabl=
e problems and building on success it proports to nearly redefine the way th=
e telecom industry works and redesign how its numbering and addressing works=
.

Second, the concept of E.164 numbering administration is a sovereign respon=
sibility of nation states as we have no requirements from NRA=E2=80=99s on what th=
ere requirements actually are, or if they really care.   And is not clear th=
at that expertise is in the IETF.  Some of us have been to this Rodeo before=
 and it did not necessarily turn out well.  Oh and the gratuitous ENUM bashi=
ng gets old after a while.

Third.. The concept of highly distributed synchronized databases is in fact=
 useful. White Spaces proved that but the operational experience in that app=
lication is still thin. I echo Penn Pfautz comments something like this coul=
d, maybe, possibly, be useful, but certainly not for the number allocation a=
pplication the proposed problem statement. Right now that application is too=
 set in concrete. I do not know one NA based service provider that is prepar=
ed to look at something new for this.   There ARE examples of de novo metada=
ta for telephone numbers where this might be useful but a rational standardi=
zation strategy would not to define a protocol through the Open Standards pr=
ocess but engage in a Open Source project. Prove the solution via running co=
de FIRST and then consider standardizing the solution set=E2=80=A6

And some of us can=E2=80=99t afford to engage in the Internet Engineering Travel =
Club..tm  especially when the block is 300 rooms.

Same time next year.. Happy New Year  :-)  See you in Berlin=E2=80=A6 :-)





Alissa



I'll
note that the question of existence has already been asked and
answered based on earlier discussions, so you'll need to show up
with previously unmade arguments.

But that conversation doesn't have bearing on whether this document
is a good match for the WG charter.


RS> The conversation is this a proper WG item .. We say NO.






/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

________________________________
Switch to Sprint and save 50% on Verizon, AT&T or T-Mobile rates. Your savi=
ngs are guaranteed until 2018! Available on most plans. Limited time offer. =
Exclusions and restrictions apply. See sprint.com/save50 for details.

________________________________

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



--B_3533201855_847884571
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable



=
From:  Brian Rosen <br@brianrosen.net>
Date:  Thursday, December 17, 2015 at 12:17 PM
To:  "Pierc=
e.Gorman@sprint.com" <Pierc=
e.Gorman@sprint.com>
Cc:  Ri=
chard Shockey <richard@shockey.us=
>, Alissa Cooper <alissa@cooperw.in=
>, Steve Donovan <srdono=
van@usdonovans.com>, Richard Hill <rhill@hill-a.ch>, "modern@ietf.org=
" <modern@ietf.org>, Adam Roa=
ch <adam@nostrum.com>
Subject:  Re: [Modern] Problem statement draf=
t as working group document

It happens.

It also happe=
ns that there is great skepticism that some new work will in fact actually b=
e deployed, and yet it does get deployed, so I wouldn’t take your obse=
rvation too far.

One of =
the great truisms of IETF, among other standards organizations is that it=
217;s really hard to stop work where there is a sufficiently large group of =
people interested in pursuing, as long as it falls within the expertise of t=
he organization.  

RS> W=
hich some of us dispute. I really really believe that E.164 numbering alloca=
tion is not within the Expertise of the IETF.  


That’s what is happening here.  It doesnR=
17;t matter that there is a large (even larger) group of people who want the=
 work stopped.

RS>  Yes =
it does matter.  That is not what I was taught consensus was.  May=
be Donald Trump’s idea of consensus.  
"My way or the h=
ighway.”  
“My protocol …right or wrong!!&#=
8221;
“Lets make the IETF great again! “   sorry =
couldn’t resist that one. 


There are enough of us who believe this work is impo=
rtant, will be implemented, and will likely supplant current ways of doing t=
hings. 

RS> So what is actual=
ly your agenda here? If your agenda is really to overthrow the existing nati=
onal E.164 numbering administration model then just say so. 
=

 “We think the FCC, CRTC, OFCOM etc guys are are a=
 bunch of <fill in the blank>."   “The E.164 Liberation Fro=
nt”  There is a T-Shirt for you. 

<=
br>
 You may not, that’s your privilege.  But =
we’re going to do the work.  It may be a waste of time.  We&=
#8217;re willing to take that chance.

=

Brian

On Dec 17, 2015, at 12:03 PM, Gorman, Pierce A [=
CTO] <Pierce.Gorman@sp=
rint.com> wrote:

I'm a newbie at IETF pr=
ocesses.  I've thought of RFCs as documents intended to solve new probl=
ems or older problems but in some better more useful way then was possible w=
ith existing standards.

Many RFCs have been issued which never enjoyed a real-live mater=
ial implementation.  I've sometimes wondered if the authors and adminis=
trators had known in advance that their efforts would be fruitless (perhaps =
even mocked), would they have pursued the effort anyway?

I think I have my answer.

-----Original Mes=
sage-----
From: M=
odern [mailto:modern-bounce=
s@ietf.org] On Behalf Of=
 Richard Shockey
=
Sent: December 16, 2015 4:21 PM
To: Alissa Cooper <alissa@cooperw.in>=
;
Cc: modern@ietf.org; Steve=
 Donovan <srdonovan@usd=
onovans.com>; Richard=
 Hill <rhill@hill-a.ch>; Adam Roach <adam@nostrum.com>
Subject: Re: [Modern] Problem statement draft as working group docu=
ment


Hi Richard,
<=
br class=3D"">
On Dec 14, 2015, at 7:02 PM, Ri=
chard Shockey <richard@shock=
ey.us> wrote:



On 1=
2/14/15, 2:36 PM, "Modern on behalf of Adam Roach" <modern-bounces@ietf.org on behalf of adam@nostrum.com> wrote:

On 12/14/15 13:16, Richar=
d Hill wrote:
From: Modern [mailto:modern-bounces@ietf.or=
g] On Behalf Of Adam
Roach

I think this document is a good starting point for =
outlining the
basic shape of the problem and the use cases MODER=
N is intended to address.
Yes, but it seems to me t=
o be placing the cart before the horse.
The draft is outlining t=
echnical solutions for things that aren't,
as far as I know, yet=
 possible from a regulatory point of view.

Where you see a cart and a horse, I see a chicken and an egg.
Someone has to go first. If taken in the opposite order, your
objection could easily be reversed to read "the proposed regulations
are outlining requirements for solutions that aren't, as far as I
know, yet technically possible."

In any cas=
e, what we say on the topic in *this* forum is largely
academic,=
 since it's not the WG participants or even the chairs that
deci=
de to start and end WGs. If you'd like to debate the existence
o=
f MODERN -- which seems to be your implied intent -- that's a
br=
oader conversation that you need to take up with the ADs and the IESG.


RS> Adam our objections wer=
e NOT considered during the charter phase here.  This was the worst cha=
rtering process I’ve ever witnessed in the IETF. And I personally blam=
e the IESG here for ignoring our concerns. And the sponsoring AD in particul=
ar..the record on that is clear.

IR=
17;m sorry that you feel that way. There was an extended amount of discussio=
n about the charter with substantial revisions made in response to points ra=
ised by you and others. As per usual in the IETF, I think we landed in a pla=
ce where no one got quite what they wanted.


RS> Well we are g=
oing to have to disagree. This process has made a fair number of people &nbs=
p;angry. The email record is quite clear that the legitimate concern of some=
 of us about Charter/WG overreach was not considered or flatly ignored in th=
e final decision to charter this work.  Its the worst chartering excers=
ise I’ve experienced in a long time.




This WG will be held to the same standard as =
all others. At chartering time, we had interest from multiple parties in see=
ing the chartered work through to completion, and we’ve seen some indi=
vidual contributions in the meantime beyond the problem statement. But if mo=
tivation wanes and can’t be rekindled through efforts by the chairs an=
d interested participants, we always have the option of closing the group.

RS> It serves no purpose to debate this further this year.  Pe=
terson is
RS> =
right, for once, … we should not disturb the needs of the many to
RS> get their Star=
 Wars tickets on time




Folks who object to the problem statement because the=
y do not believe there is a problem here the IETF can solve have been heard,=
 I think.




RS> I’m afraid, once again you really do=
n’t understand,

One, the charter is so overreaching as to be functionally useless.=
 It violates every rational way the IETF works. Instead of choosing descrete=
 definable problems and building on success it proports to nearly redefine t=
he way the telecom industry works and redesign how its numbering and address=
ing works.

S=
econd, the concept of E.164 numbering administration is a sovereign responsi=
bility of nation states as we have no requirements from NRA’s on what =
there requirements actually are, or if they really care.   And is =
not clear that that expertise is in the IETF.  Some of us have been to =
this Rodeo before and it did not necessarily turn out well.  Oh and the=
 gratuitous ENUM bashing gets old after a while.

Third.. The concept of highly distribut=
ed synchronized databases is in fact useful. White Spaces proved that but th=
e operational experience in that application is still thin. I echo Penn Pfau=
tz comments something like this could, maybe, possibly, be useful, but certa=
inly not for the number allocation application the proposed problem statemen=
t. Right now that application is too set in concrete. I do not know one NA b=
ased service provider that is prepared to look at something new for this. &n=
bsp; There ARE examples of de novo metadata for telephone numbers where=
 this might be useful but a rational standardization strategy would not to d=
efine a protocol through the Open Standards process but engage in a Open Sou=
rce project. Prove the solution via running code FIRST and then consider sta=
ndardizing the solution set…

And some of us can’t afford to engage in the In=
ternet Engineering Travel Club..tm  especially when the block is 300 ro=
oms.

Same ti=
me next year.. Happy New Year  :-)  See you in Berlin… :-)





=
Alissa



I'll
note that t=
he question of existence has already been asked and
answered bas=
ed on earlier discussions, so you'll need to show up
with previo=
usly unmade arguments.

But that conversation doesn'=
t have bearing on whether this document
is a good match for the =
WG charter.


RS> The co=
nversation is this a proper WG item .. We say NO.
<=
br class=3D"">




/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 listModern@ietf.org
https://www.ietf.org/mailman/listinfo/modern

_______________________________=
_
Switch to Sprin=
t and save 50% on Verizon, AT&T or T-Mobile rates. Your savings are guar=
anteed until 2018! Available on most plans. Limited time offer. Exclusions a=
nd restrictions apply. See <=
/span>sprint.com/save50<http://sprint.com/50off> for details.

________________________________

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

=


--B_3533201855_847884571--



From nobody Thu Dec 17 10:19:35 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D241B3028 for ; Thu, 17 Dec 2015 10:19:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2uzjxbYg03P for ; Thu, 17 Dec 2015 10:19:32 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 E67C51B3022 for ; Thu, 17 Dec 2015 10:19:32 -0800 (PST)
Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id tBHHoggt016608; Thu, 17 Dec 2015 13:19:26 -0500
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 1ytsjgkew0-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);  Thu, 17 Dec 2015 13:19:26 -0500
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 tBHIJOSt014509; Thu, 17 Dec 2015 13:19:25 -0500
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 tBHIJEOp014394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 17 Dec 2015 13:19:19 -0500
Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Thu, 17 Dec 2015 18:18:57 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.78]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0248.002; Thu, 17 Dec 2015 13:18:56 -0500
From: "DOLLY, MARTIN C" 
To: Adam Roach , Richard Hill , "'Brian Rosen'" , "'Gorman, Pierce A [CTO]'" 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHROEiYt9tG2eQFXECnCpoLN3xbKp7OlCAAgADTIpCAAFmaAIAADhaAgAABNID//6x4gA==
Date: Thu, 17 Dec 2015 18:18:56 +0000
Message-ID: 
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com> <056701d136a3$e1c49120$a54db360$@ch> <566F1A34.9020402@nostrum.com> <6C827E0C-682C-4484-8F21-20A446746858@shockey.us> <0F2A509D-5DEA-4416-BEEF-3D814C4D02E3@cooperw.in>   <62D8976B-8132-4C80-9656-6A3BD6853EE8@brianrosen.net> <007c01d138f5$db461040$91d230c0$@ch> <5672FAFB.2060802@nostrum.com>
In-Reply-To: <5672FAFB.2060802@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.193.27]
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-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-12-17_02:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310007 definitions=main-1512170292
Archived-At: 
Cc: 'Steve Donovan' , "modern@ietf.org" , 'Alissa Cooper' , 'Richard Shockey' 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 17 Dec 2015 18:19:34 -0000

Adam,

The problem here though is that these capabilities are driven by regulatory=
 body (singular), as in the FCC.=20

They have not officially provided their requirements, thereby I go back to =
my folksy comment that, "how does a carpenter know what tools to bring to a=
 job if he does not know what he is building?"

As I stated previously, there is a practical aspect to this work, but a lot=
 of theory is being thrown around.

Regards,

Martin=20

-----Original Message-----
From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Adam Roach
Sent: Thursday, December 17, 2015 1:12 PM
To: Richard Hill ; 'Brian Rosen' ; 'Gor=
man, Pierce A [CTO]' 
Cc: modern@ietf.org; 'Steve Donovan' ; 'Alissa Co=
oper' ; 'Richard Shockey' 
Subject: Re: [Modern] Problem statement draft as working group document

On 12/17/15 12:07, Richard Hill wrote:
> Can you (or somebody else) explain to me how processes (which might have =
regulatory implications) regarding assignment of E.164 numbers fall within =
the expertise of the IETF?
>
> Or have I misunderstood the scope of the work of this group?

You have misunderstood the scope of the entire IETF. We design network prot=
ocols. We are not part of any regulatory bodies. What those bodies choose t=
o do is entirely in their purview.

/a

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


From nobody Thu Dec 17 10:20:01 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98521A1C04 for ; Thu, 17 Dec 2015 10:19:59 -0800 (PST)
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 mnUbgvJROMRB for ; Thu, 17 Dec 2015 10:19:58 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EFE11A6F1D for ; Thu, 17 Dec 2015 10:19:58 -0800 (PST)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tBHIJuQu077142 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 17 Dec 2015 12:19:57 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
To: "DOLLY, MARTIN C" 
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com> <056701d136a3$e1c49120$a54db360$@ch> <566F1A34.9020402@nostrum.com> <6C827E0C-682C-4484-8F21-20A446746858@shockey.us> <0F2A509D-5DEA-4416-BEEF-3D814C4D02E3@cooperw.in>   <5672ED88.3090106@nostrum.com> 
From: Adam Roach 
Message-ID: <5672FCCC.3080609@nostrum.com>
Date: Thu, 17 Dec 2015 12:19:56 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: Steve Donovan , Alissa Cooper , "modern@ietf.org" , Richard Shockey , "Gorman, Pierce A \[CTO\]" , Richard Hill 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 17 Dec 2015 18:19:59 -0000

Yes, and I think it's safe to say that your evaluation of the potential 
deployment of the protocols designed by MODERN differs from Mr. 
Gorman's. Based on that, your evaluation about whether and how to 
participate is different. I would offer that the calculus from your 
perspective would point to positive WG contributions, to assist in 
producing protocols that are well-designed and incorporate your 
expertise in the area.

/a

On 12/17/15 11:26, DOLLY, MARTIN C wrote:
> Adam
>
> There are practical aspects of Modern, but a lot of theory too.  Be honest.
>
> Martin C Dolly
> Lead Member of Technical Staff
> Core & Government/Regulatory Standards
> AT&T
> Cell: 609-903-3360
> Email: md3135@att.com
>
>> On Dec 17, 2015, at 12:15 PM, Adam Roach  wrote:
>>
>>> On 12/17/15 11:03, Gorman, Pierce A [CTO] wrote:
>>> Many RFCs have been issued which never enjoyed a real-live material implementation.  I've sometimes wondered if the authors and administrators had known in advance that their efforts would be fruitless (perhaps even mocked), would they have pursued the effort anyway?
>>>
>>> I think I have my answer.
>> If you don't think the work MODERN is doing will produce useful output, then I encourage you to find other ways to spend your time than trying to stop work. If your analysis is correct, the impact on you or anything you care about is approximately zero.
>>
>> /a
>>
>> _______________________________________________
>> Modern mailing list
>> Modern@ietf.org
>> https://www.ietf.org/mailman/listinfo/modern
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern


From nobody Thu Dec 17 10:23:27 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E911A87C4 for ; Thu, 17 Dec 2015 10:23:25 -0800 (PST)
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 m3twhdlwBj9w for ; Thu, 17 Dec 2015 10:23:24 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D76371A8738 for ; Thu, 17 Dec 2015 10:23:24 -0800 (PST)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tBHINNlb077507 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 17 Dec 2015 12:23:24 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
To: Richard Shockey , Brian Rosen , "Gorman, Pierce A [CTO]" 
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com> <056701d136a3$e1c49120$a54db360$@ch> <566F1A34.9020402@nostrum.com> <6C827E0C-682C-4484-8F21-20A446746858@shockey.us> <0F2A509D-5DEA-4416-BEEF-3D814C4D02E3@cooperw.in>   <62D8976B-8132-4C80-9656-6A3BD6853EE8@brianrosen.net> <7082DBCA-ABC9-4DFD-90EC-32C5EEEE078C@shockey.us>
From: Adam Roach 
Message-ID: <5672FD9B.6060008@nostrum.com>
Date: Thu, 17 Dec 2015 12:23:23 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <7082DBCA-ABC9-4DFD-90EC-32C5EEEE078C@shockey.us>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: Steve Donovan , Richard Hill , "modern@ietf.org" , Alissa Cooper 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 17 Dec 2015 18:23:26 -0000

On 12/17/15 11:57, Richard Shockey wrote:
> RS> Which some of us dispute. I really really believe that E.164 
> numbering allocation is not within the Expertise of the IETF.

An incredibly congruent objection was raised by several parties in the 
chartering of CODEC. The result of proceeding anyway was objectively and 
subjectively the best audio codec ever produced.

/a


From nobody Thu Dec 17 10:27:24 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824C91B2C0F for ; Thu, 17 Dec 2015 10:27:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AiOZNZgXhma for ; Thu, 17 Dec 2015 10:27:22 -0800 (PST)
Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C58E91A9171 for ; Thu, 17 Dec 2015 10:27:21 -0800 (PST)
Received: from smtp3.infomaniak.ch (smtp3.infomaniak.ch [84.16.68.91]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBHIRAXp015381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 17 Dec 2015 19:27:10 +0100
Received: from RHillNew (adsl-178-38-52-133.adslplus.ch [178.38.52.133]) (authenticated bits=0) by smtp3.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBHIR5kb017560; Thu, 17 Dec 2015 19:27:05 +0100
From: "Richard Hill" 
To: "'Adam Roach'" , "'Brian Rosen'" , "'Gorman, Pierce A [CTO]'" 
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com> <056701d136a3$e1c49120$a54db360$@ch> <566F1A34.9020402@nostrum.com> <6C827E0C-682C-4484-8F21-20A446746858@shockey.us> <0F2A509D-5DEA-4416-BEEF-3D814C4D02E3@cooperw.in>   <62D8976B-8132-4C80-9656-6A3BD6853EE8@brianrosen.net> <007c01d138f5$db461040$91d230c0$@ch> <5672FAFB.2060802@nostrum.com>
In-Reply-To: <5672FAFB.2060802@nostrum.com>
Date: Thu, 17 Dec 2015 19:27:06 +0100
Message-ID: <00be01d138f8$8bca7080$a35f5180$@ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdE49neXLuHKCZrDTmi9YLOSAqD/oAAAdxrA
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, 'Steve Donovan' , 'Alissa Cooper' , 'Richard Shockey' 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 17 Dec 2015 18:27:23 -0000

> -----Original Message-----
> From: Adam Roach [mailto:adam@nostrum.com]
> Sent: Thursday, December 17, 2015 19:12
> To: Richard Hill; 'Brian Rosen'; 'Gorman, Pierce A [CTO]'
> Cc: 'Richard Shockey'; 'Alissa Cooper'; 'Steve Donovan';
> modern@ietf.org
> Subject: Re: [Modern] Problem statement draft as working group =
document
>=20
> On 12/17/15 12:07, Richard Hill wrote:
> > Can you (or somebody else) explain to me how processes (which might
> have regulatory implications) regarding assignment of E.164 numbers
> fall within the expertise of the IETF?
> >
> > Or have I misunderstood the scope of the work of this group?
>=20
> You have misunderstood the scope of the entire IETF. We design network
> protocols. We are not part of any regulatory bodies. What those bodies
> choose to do is entirely in their purview.


Are you implying that the IETF can design a protocol without any =
reference whatsoever to whether it might violate existing laws and =
regulations?

>=20
> /a


From nobody Thu Dec 17 11:23:39 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CF41A88CB for ; Thu, 17 Dec 2015 11:23:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level: 
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8OID0PgEmfL for ; Thu, 17 Dec 2015 11:23:36 -0800 (PST)
Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id DF64B1A88A6 for ; Thu, 17 Dec 2015 11:23:35 -0800 (PST)
Received: (qmail 17968 invoked by uid 0); 17 Dec 2015 19:23:22 -0000
Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy2.mail.unifiedlayer.com with SMTP; 17 Dec 2015 19:23:22 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with  id uj391r00d1MNPNq01j3C2F; Thu, 17 Dec 2015 12:03:22 -0700
X-Authority-Analysis: v=2.1 cv=IekUBwaa c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=0BRvPPsJEo4A:10 a=wUQvQvOEmiQA:10 a=jqBRFv0mrdUA:10 a=Z80JlwQ0AAAA:8 a=yX4uVSVs9CjpW7Cf0hIA:9 a=QEXdDO2ut3YA: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=OlY3B8jCe3sMcmoj1LgQ1uY6L+I/8wDj56KoCWzaaW4=;  b=NJQ8Bo+SgsAv/Bc1V57ZfFagJrMJAE2Ykw1z/mFpYtXu8TBCfo7+9vufiw/bA6nVyiOGpvtuK4Sw3ZiDG7ibGl82VJ5BFDOh4axnuL2Un1xebSyZGTSThW88GDUwZImk;
Received: from [50.241.241.5] (port=51399 helo=[172.20.2.220]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1a9dpV-0007qx-Bf; Thu, 17 Dec 2015 12:03:09 -0700
User-Agent: Microsoft-MacOutlook/0.0.0.151105
Date: Thu, 17 Dec 2015 14:03:00 -0500
From: Richard Shockey 
To: Adam Roach , Brian Rosen , "Gorman, Pierce A [CTO]" 
Message-ID: <482C4AF8-21CD-4F08-B0B8-E3BDC6A06F95@shockey.us>
Thread-Topic: [Modern] Problem statement draft as working group document
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com> <056701d136a3$e1c49120$a54db360$@ch> <566F1A34.9020402@nostrum.com> <6C827E0C-682C-4484-8F21-20A446746858@shockey.us> <0F2A509D-5DEA-4416-BEEF-3D814C4D02E3@cooperw.in>   <62D8976B-8132-4C80-9656-6A3BD6853EE8@brianrosen.net> <7082DBCA-ABC9-4DFD-90EC-32C5EEEE078C@shockey.us> <5672FD9B.6060008@nostrum.com>
In-Reply-To: <5672FD9B.6060008@nostrum.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 50.241.241.5 authed with richard+shockey.us}
Archived-At: 
Cc: Steve Donovan , Richard Hill , "modern@ietf.org" , Alissa Cooper 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 17 Dec 2015 19:23:37 -0000

I remember that objection well. And Yes the outcome was outstanding but the analogy is not applicable to the problem statement.  CODEC was actually an engineering effort ..this is objectively and subjectively political. 





On 12/17/15, 1:23 PM, "Adam Roach"  wrote:

>On 12/17/15 11:57, Richard Shockey wrote:
>> RS> Which some of us dispute. I really really believe that E.164 
>> numbering allocation is not within the Expertise of the IETF.
>
>An incredibly congruent objection was raised by several parties in the 
>chartering of CODEC. The result of proceeding anyway was objectively and 
>subjectively the best audio codec ever produced.
>
>/a


From nobody Thu Dec 17 11:24: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 B8C911A8902 for ; Thu, 17 Dec 2015 11:24:09 -0800 (PST)
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 emXgnQRBSz0Z for ; Thu, 17 Dec 2015 11:24:08 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7BFE1A88CB for ; Thu, 17 Dec 2015 11:24:08 -0800 (PST)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tBHJO73v082641 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 17 Dec 2015 13:24:07 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
To: Richard Hill , "'Brian Rosen'" , "'Gorman, Pierce A [CTO]'" 
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com> <056701d136a3$e1c49120$a54db360$@ch> <566F1A34.9020402@nostrum.com> <6C827E0C-682C-4484-8F21-20A446746858@shockey.us> <0F2A509D-5DEA-4416-BEEF-3D814C4D02E3@cooperw.in>   <62D8976B-8132-4C80-9656-6A3BD6853EE8@brianrosen.net> <007c01d138f5$db461040$91d230c0$@ch> <5672FAFB.2060802@nostrum.com> <00be01d138f8$8bca7080$a35f5180$@ch>
From: Adam Roach 
Message-ID: <56730BD7.4020902@nostrum.com>
Date: Thu, 17 Dec 2015 13:24:07 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <00be01d138f8$8bca7080$a35f5180$@ch>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: modern@ietf.org, 'Steve Donovan' , 'Alissa Cooper' , 'Richard Shockey' 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 17 Dec 2015 19:24:09 -0000

On 12/17/15 12:27, Richard Hill wrote:
> Are you implying that the IETF can design a protocol without any reference whatsoever to whether it might violate existing laws and regulations?

Many of the people on this mailing list have spent time over the past 18 
years working on VoIP technologies in the IETF. During this development, 
VoIP was at one time or another illegal or effectively forbidden by 
regulation in China, India, Pakistan, Nepal, Uzbekistan, Nicaragua, 
Colombia, Bolivia, Guyana, Paraguay, Costa Rica, Belize, many Caribbean 
nations, and most of the middle east. In fact, until mid-2008, somewhere 
around 40% of the world's population lived in a country that effectively 
outlawed VoIP.

There's good precedent for the IETF developing protocols whose 
deployment at the moment of development would be subject to legal or 
regulatory restrictions in some jurisdictions.

/a


From nobody Thu Dec 17 11:43:01 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4781B3042 for ; Thu, 17 Dec 2015 11:42:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jo6YSuFY65P8 for ; Thu, 17 Dec 2015 11:42:57 -0800 (PST)
Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AA0B1B303F for ; Thu, 17 Dec 2015 11:42:57 -0800 (PST)
Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBHJgnPs030192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 17 Dec 2015 20:42:49 +0100
Received: from RHillNew (adsl-178-38-52-133.adslplus.ch [178.38.52.133]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBHJgj8d003657; Thu, 17 Dec 2015 20:42:46 +0100
From: "Richard Hill" 
To: "'Adam Roach'" , "'Brian Rosen'" , "'Gorman, Pierce A [CTO]'" 
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com> <056701d136a3$e1c49120$a54db360$@ch> <566F1A34.9020402@nostrum.com> <6C827E0C-682C-4484-8F21-20A446746858@shockey.us> <0F2A509D-5DEA-4416-BEEF-3D814C4D02E3@cooperw.in>   <62D8976B-8132-4C80-9656-6A3BD6853EE8@brianrosen.net> <007c01d138f5$db461040$91d230c0$@ch> <5672FAFB.2060802@nostrum.com> <00be01d138f8$8bca7080$a35f5180$@ch> <56730BD7.4020902@nostrum.com>
In-Reply-To: <56730BD7.4020902@nostrum.com>
Date: Thu, 17 Dec 2015 20:42:47 +0100
Message-ID: <00e001d13903$1cce9200$566bb600$@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: AdE5AIQheleMRdwrQKCZnNM1T0u8ogAAivUQ
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: 'Steve Donovan' , modern@ietf.org, 'Alissa Cooper' , 'Richard Shockey' 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 17 Dec 2015 19:42:59 -0000

> -----Original Message-----
> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Adam Roach
> Sent: Thursday, December 17, 2015 20:24
> To: Richard Hill; 'Brian Rosen'; 'Gorman, Pierce A [CTO]'
> Cc: modern@ietf.org; 'Steve Donovan'; 'Alissa Cooper'; 'Richard
> Shockey'
> Subject: Re: [Modern] Problem statement draft as working group document
> 

SNIP

> There's good precedent for the IETF developing protocols whose
> deployment at the moment of development would be subject to legal or
> regulatory restrictions in some jurisdictions.

Of course. There is nothing wrong with developing a protocol that that is
legal in some place and not legal elsewhere, because it can be used in the
countries in which it is legal.

Would the protocols proposed to be developed in this group conform to
current legal and regulatory requirements in at least one jurisdiction?  Or
is that question not relevant?

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


From nobody Thu Dec 17 11:49: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 9CAD21B3044 for ; Thu, 17 Dec 2015 11:49:06 -0800 (PST)
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 t_4mtVAI9vcF for ; Thu, 17 Dec 2015 11:49:05 -0800 (PST)
Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEC251B3043 for ; Thu, 17 Dec 2015 11:49:04 -0800 (PST)
Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.15.0.59/8.15.0.59) with SMTP id tBHJkSHD032755 for ; Thu, 17 Dec 2015 14:49:00 -0500
Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 1ytssh524b-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 17 Dec 2015 14:49:00 -0500
Received: from STNTEXMB11.cis.neustar.com ([169.254.1.102]) by stntexhc10.cis.neustar.com ([169.254.4.121]) with mapi id 14.03.0158.001; Thu, 17 Dec 2015 14:48:59 -0500
From: "McGarry, Tom" 
To: "modern@ietf.org" 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHRHl26DyraNZUDF0WIF1b3d5Qwlp7FC3CAgAZM7ICAAAZ7gIAABakAgABKWoCAAvlsgIAADuwAgAE5mICAAAPoAIAADhaAgAABM4CAAAQrAP//wwuA
Date: Thu, 17 Dec 2015 19:48:59 +0000
Message-ID: 
In-Reply-To: <00be01d138f8$8bca7080$a35f5180$@ch>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.2.130206
x-originating-ip: [10.33.205.69]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-12-17_03:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310007 definitions=main-1512170307
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 17 Dec 2015 19:49:06 -0000

What's being designed are tools.  It is up to others, e.g., regulators,
authorities, to decide how or whether to use those tools.  That's where
the policy gets created.

I know it has been controversial to suggest a tool (process) that would
allow a consumer to acquire a telephone number directly, rather than thru
a service provider.  The most common identifier on the Internet, domain
names, uses this model.  We're discussing identifiers, telephone numbers,
on IP networks.  It would be irresponsible and backward looking not to
account for this possibility.
=20
The WG also includes the current process for number allocation, where
service providers acquire the numbers and they then in turn allocate
numbers to consumers.

Entities that decide numbering policies can choose which tools they do and
do not want to use.  That is where policies and regulations are created.

I know some people on this list refuse to believe this, not matter how
often it is said.  But those are the facts.


   =20

On 12/17/15 1:27 PM, "Richard Hill"  wrote:

>
>
>> -----Original Message-----
>> From: Adam Roach [mailto:adam@nostrum.com]
>> Sent: Thursday, December 17, 2015 19:12
>> To: Richard Hill; 'Brian Rosen'; 'Gorman, Pierce A [CTO]'
>> Cc: 'Richard Shockey'; 'Alissa Cooper'; 'Steve Donovan';
>> modern@ietf.org
>> Subject: Re: [Modern] Problem statement draft as working group document
>>=20
>> On 12/17/15 12:07, Richard Hill wrote:
>> > Can you (or somebody else) explain to me how processes (which might
>> have regulatory implications) regarding assignment of E.164 numbers
>> fall within the expertise of the IETF?
>> >
>> > Or have I misunderstood the scope of the work of this group?
>>=20
>> You have misunderstood the scope of the entire IETF. We design network
>> protocols. We are not part of any regulatory bodies. What those bodies
>> choose to do is entirely in their purview.
>
>
>Are you implying that the IETF can design a protocol without any
>reference whatsoever to whether it might violate existing laws and
>regulations?
>
>>=20
>> /a
>
>_______________________________________________
>Modern mailing list
>Modern@ietf.org
>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma=
n_
>listinfo_modern&d=3DCwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI=
DcLext
>Z1ooNcfp01IYIaVqsORjI&m=3DozfZfjKsWcLVXeIljVVsmxlsctjUYK9cpOGjPZWtBkw&s=3D=
LPGP
>t7cTP8zbe-1ZBrkEgho_MZXUC-S7QX5pGaOvL0U&e=3D=20


From nobody Thu Dec 17 12:00:27 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877D61B30C9 for ; Thu, 17 Dec 2015 12:00:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXJfyv9zZp-K for ; Thu, 17 Dec 2015 12:00:24 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 431C41B30BA for ; Thu, 17 Dec 2015 12:00:22 -0800 (PST)
Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id tBHK0Gch001257; Thu, 17 Dec 2015 15:00:22 -0500
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by mx0a-00191d01.pphosted.com with ESMTP id 1ytsjgvh62-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);  Thu, 17 Dec 2015 15:00:21 -0500
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 tBHK0KKX020508; Thu, 17 Dec 2015 15:00:20 -0500
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 tBHK0CIL020323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 17 Dec 2015 15:00:17 -0500
Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 17 Dec 2015 20:00:06 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.78]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0248.002; Thu, 17 Dec 2015 15:00:05 -0500
From: "DOLLY, MARTIN C" 
To: "McGarry, Tom" 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHROEiYt9tG2eQFXECnCpoLN3xbKp7OlCAAgADTIpCAAFmaAIAADhaAgAABNICAAAQrAIAAFuCA//+vSag=
Date: Thu, 17 Dec 2015 20:00:05 +0000
Message-ID: 
References: <00be01d138f8$8bca7080$a35f5180$@ch>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-12-17_03:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310007 definitions=main-1512170323
Archived-At: 
Cc: "modern@ietf.org" 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 17 Dec 2015 20:00:26 -0000

Tom=20

That is the point and frustration, shouldn't we have an understanding of th=
e regulatory requirements before blindly defining protocol?

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards=20
AT&T
Cell: 609-903-3360
Email: md3135@att.com

> On Dec 17, 2015, at 2:49 PM, McGarry, Tom  wrote=
:
>=20
> What's being designed are tools.  It is up to others, e.g., regulators,
> authorities, to decide how or whether to use those tools.  That's where
> the policy gets created.
>=20
> I know it has been controversial to suggest a tool (process) that would
> allow a consumer to acquire a telephone number directly, rather than thru
> a service provider.  The most common identifier on the Internet, domain
> names, uses this model.  We're discussing identifiers, telephone numbers,
> on IP networks.  It would be irresponsible and backward looking not to
> account for this possibility.
>=20
> The WG also includes the current process for number allocation, where
> service providers acquire the numbers and they then in turn allocate
> numbers to consumers.
>=20
> Entities that decide numbering policies can choose which tools they do an=
d
> do not want to use.  That is where policies and regulations are created.
>=20
> I know some people on this list refuse to believe this, not matter how
> often it is said.  But those are the facts.
>=20
>=20
>=20
>=20
>> On 12/17/15 1:27 PM, "Richard Hill"  wrote:
>>=20
>>=20
>>=20
>>> -----Original Message-----
>>> From: Adam Roach [mailto:adam@nostrum.com]
>>> Sent: Thursday, December 17, 2015 19:12
>>> To: Richard Hill; 'Brian Rosen'; 'Gorman, Pierce A [CTO]'
>>> Cc: 'Richard Shockey'; 'Alissa Cooper'; 'Steve Donovan';
>>> modern@ietf.org
>>> Subject: Re: [Modern] Problem statement draft as working group document
>>>=20
>>>> On 12/17/15 12:07, Richard Hill wrote:
>>>> Can you (or somebody else) explain to me how processes (which might
>>> have regulatory implications) regarding assignment of E.164 numbers
>>> fall within the expertise of the IETF?
>>>>=20
>>>> Or have I misunderstood the scope of the work of this group?
>>>=20
>>> You have misunderstood the scope of the entire IETF. We design network
>>> protocols. We are not part of any regulatory bodies. What those bodies
>>> choose to do is entirely in their purview.
>>=20
>>=20
>> Are you implying that the IETF can design a protocol without any
>> reference whatsoever to whether it might violate existing laws and
>> regulations?
>>=20
>>>=20
>>> /a
>>=20
>> _______________________________________________
>> Modern mailing list
>> Modern@ietf.org
>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail=
man_
>> listinfo_modern&d=3DCwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve=
eIDcLext
>> Z1ooNcfp01IYIaVqsORjI&m=3DozfZfjKsWcLVXeIljVVsmxlsctjUYK9cpOGjPZWtBkw&s=
=3DLPGP
>> t7cTP8zbe-1ZBrkEgho_MZXUC-S7QX5pGaOvL0U&e=3D
>=20
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern


From nobody Thu Dec 17 12:04:46 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46B51B3062 for ; Thu, 17 Dec 2015 12:04:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04S144JW6bIO for ; Thu, 17 Dec 2015 12:04:41 -0800 (PST)
Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8469F1B3060 for ; Thu, 17 Dec 2015 12:04:41 -0800 (PST)
Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBHK4dCa015815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 17 Dec 2015 21:04:39 +0100
Received: from RHillNew (adsl-178-38-52-133.adslplus.ch [178.38.52.133]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBHK4c9T027683; Thu, 17 Dec 2015 21:04:38 +0100
From: "Richard Hill" 
To: "'McGarry, Tom'" , 
References: <00be01d138f8$8bca7080$a35f5180$@ch> 
In-Reply-To: 
Date: Thu, 17 Dec 2015 21:04:39 +0100
Message-ID: <00ee01d13906$29b43d00$7d1cb700$@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: AQHRHl26DyraNZUDF0WIF1b3d5Qwlp7FC3CAgAZM7ICAAAZ7gIAABakAgABKWoCAAvlsgIAADuwAgAE5mICAAAPoAIAADhaAgAABM4CAAAQrAP//wwuAgAAEUgA=
Content-Language: en-us
X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8
X-Antivirus-Code: 0x100000
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 17 Dec 2015 20:04:44 -0000

Thank you for clarifying.

Best,
Richard

> -----Original Message-----
> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
> Sent: Thursday, December 17, 2015 20:49
> To: modern@ietf.org
> Subject: Re: [Modern] Problem statement draft as working group document
> 
> What's being designed are tools.  It is up to others, e.g., regulators,
> authorities, to decide how or whether to use those tools.  That's where
> the policy gets created.
> 
> I know it has been controversial to suggest a tool (process) that would
> allow a consumer to acquire a telephone number directly, rather than
> thru a service provider.  The most common identifier on the Internet,
> domain names, uses this model.  We're discussing identifiers, telephone
> numbers, on IP networks.  It would be irresponsible and backward
> looking not to account for this possibility.
> 
> The WG also includes the current process for number allocation, where
> service providers acquire the numbers and they then in turn allocate
> numbers to consumers.
> 
> Entities that decide numbering policies can choose which tools they do
> and do not want to use.  That is where policies and regulations are
> created.
> 
> I know some people on this list refuse to believe this, not matter how
> often it is said.  But those are the facts.
> 
> 
> 
> 
> On 12/17/15 1:27 PM, "Richard Hill"  wrote:
> 
> >
> >
> >> -----Original Message-----
> >> From: Adam Roach [mailto:adam@nostrum.com]
> >> Sent: Thursday, December 17, 2015 19:12
> >> To: Richard Hill; 'Brian Rosen'; 'Gorman, Pierce A [CTO]'
> >> Cc: 'Richard Shockey'; 'Alissa Cooper'; 'Steve Donovan';
> >> modern@ietf.org
> >> Subject: Re: [Modern] Problem statement draft as working group
> >> document
> >>
> >> On 12/17/15 12:07, Richard Hill wrote:
> >> > Can you (or somebody else) explain to me how processes (which
> might
> >> have regulatory implications) regarding assignment of E.164 numbers
> >> fall within the expertise of the IETF?
> >> >
> >> > Or have I misunderstood the scope of the work of this group?
> >>
> >> You have misunderstood the scope of the entire IETF. We design
> >> network protocols. We are not part of any regulatory bodies. What
> >> those bodies choose to do is entirely in their purview.
> >
> >
> >Are you implying that the IETF can design a protocol without any
> >reference whatsoever to whether it might violate existing laws and
> >regulations?
> >
> >>
> >> /a
> >
> >_______________________________________________
> >Modern mailing list
> >Modern@ietf.org
> >https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailm
> >an_
> >listinfo_modern&d=CwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDc
> L
> >ext
> >Z1ooNcfp01IYIaVqsORjI&m=ozfZfjKsWcLVXeIljVVsmxlsctjUYK9cpOGjPZWtBkw&s=
> L
> >PGP t7cTP8zbe-1ZBrkEgho_MZXUC-S7QX5pGaOvL0U&e=
> 
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern


From nobody Thu Dec 17 12:20: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 393E31B3083 for ; Thu, 17 Dec 2015 12:20:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5aLXrBd0m_1 for ; Thu, 17 Dec 2015 12:20:36 -0800 (PST)
Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 639961B3081 for ; Thu, 17 Dec 2015 12:20:36 -0800 (PST)
Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id tBHKFq4c014497; Thu, 17 Dec 2015 15:20:35 -0500
Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1yu14f46wx-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 17 Dec 2015 15:20:34 -0500
Received: from STNTEXMB11.cis.neustar.com ([169.254.1.102]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Thu, 17 Dec 2015 15:20:33 -0500
From: "McGarry, Tom" 
To: "DOLLY, MARTIN C" 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHRHl26DyraNZUDF0WIF1b3d5Qwlp7FC3CAgAZM7ICAAAZ7gIAABakAgABKWoCAAvlsgIAADuwAgAE5mICAAAPoAIAADhaAgAABM4CAAAQrAP//wwuAgABW8ID//7HgAA==
Date: Thu, 17 Dec 2015 20:20:33 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.2.130206
x-originating-ip: [10.33.205.69]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-12-17_02:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310007 definitions=main-1512170255
Archived-At: 
Cc: "modern@ietf.org" 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 17 Dec 2015 20:20:38 -0000

No, that would get us involved with regulations and policies.  Our role is
to understand the environment from a technology and process perspective,
anticipate needs (e.g., perhaps including a more Internet-like model) and
create solutions.  It's up to others to choose what they will and will not
use. =20

On 12/17/15 3:00 PM, "DOLLY, MARTIN C"  wrote:

>Tom=20
>
>That is the point and frustration, shouldn't we have an understanding of
>the regulatory requirements before blindly defining protocol?
>
>Martin C Dolly
>Lead Member of Technical Staff
>Core & Government/Regulatory Standards
>AT&T
>Cell: 609-903-3360
>Email: md3135@att.com
>
>> On Dec 17, 2015, at 2:49 PM, McGarry, Tom 
>>wrote:
>>=20
>> What's being designed are tools.  It is up to others, e.g., regulators,
>> authorities, to decide how or whether to use those tools.  That's where
>> the policy gets created.
>>=20
>> I know it has been controversial to suggest a tool (process) that would
>> allow a consumer to acquire a telephone number directly, rather than
>>thru
>> a service provider.  The most common identifier on the Internet, domain
>> names, uses this model.  We're discussing identifiers, telephone
>>numbers,
>> on IP networks.  It would be irresponsible and backward looking not to
>> account for this possibility.
>>=20
>> The WG also includes the current process for number allocation, where
>> service providers acquire the numbers and they then in turn allocate
>> numbers to consumers.
>>=20
>> Entities that decide numbering policies can choose which tools they do
>>and
>> do not want to use.  That is where policies and regulations are created.
>>=20
>> I know some people on this list refuse to believe this, not matter how
>> often it is said.  But those are the facts.
>>=20
>>=20
>>=20
>>=20
>>> On 12/17/15 1:27 PM, "Richard Hill"  wrote:
>>>=20
>>>=20
>>>=20
>>>> -----Original Message-----
>>>> From: Adam Roach [mailto:adam@nostrum.com]
>>>> Sent: Thursday, December 17, 2015 19:12
>>>> To: Richard Hill; 'Brian Rosen'; 'Gorman, Pierce A [CTO]'
>>>> Cc: 'Richard Shockey'; 'Alissa Cooper'; 'Steve Donovan';
>>>> modern@ietf.org
>>>> Subject: Re: [Modern] Problem statement draft as working group
>>>>document
>>>>=20
>>>>> On 12/17/15 12:07, Richard Hill wrote:
>>>>> Can you (or somebody else) explain to me how processes (which might
>>>> have regulatory implications) regarding assignment of E.164 numbers
>>>> fall within the expertise of the IETF?
>>>>>=20
>>>>> Or have I misunderstood the scope of the work of this group?
>>>>=20
>>>> You have misunderstood the scope of the entire IETF. We design network
>>>> protocols. We are not part of any regulatory bodies. What those bodies
>>>> choose to do is entirely in their purview.
>>>=20
>>>=20
>>> Are you implying that the IETF can design a protocol without any
>>> reference whatsoever to whether it might violate existing laws and
>>> regulations?
>>>=20
>>>>=20
>>>> /a
>>>=20
>>> _______________________________________________
>>> Modern mailing list
>>> Modern@ietf.org
>>>=20
>>>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail=
ma
>>>n_
>>>=20
>>>listinfo_modern&d=3DCwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve=
eIDcLe
>>>xt
>>>=20
>>>Z1ooNcfp01IYIaVqsORjI&m=3DozfZfjKsWcLVXeIljVVsmxlsctjUYK9cpOGjPZWtBkw&s=
=3DLP
>>>GP
>>> t7cTP8zbe-1ZBrkEgho_MZXUC-S7QX5pGaOvL0U&e=3D
>>=20
>> _______________________________________________
>> Modern mailing list
>> Modern@ietf.org
>>=20
>>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm=
an
>>_listinfo_modern&d=3DCwIFAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve=
eIDcLe
>>xtZ1ooNcfp01IYIaVqsORjI&m=3D6k6xBxpm7dn7KBeEKiMOttP4N0RYgrEx_jL-ZEio3tc&s=
=3DR
>>wfQDsbB7PHQvmP4WR0eqfXpetHM9q0n4Pr5CuIXEVU&e=3D=20


From nobody Thu Dec 17 12:34:31 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA401B3098 for ; Thu, 17 Dec 2015 12:34:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 mcfOEahadZ0f for ; Thu, 17 Dec 2015 12:34:27 -0800 (PST)
Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B70421B3097 for ; Thu, 17 Dec 2015 12:34:25 -0800 (PST)
Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-12v.sys.comcast.net with comcast id ukaC1r0022AWL2D01kaRk3; Thu, 17 Dec 2015 20:34:25 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-04v.sys.comcast.net with comcast id ukaQ1r00J3KdFy101kaQEQ; Thu, 17 Dec 2015 20:34:25 +0000
To: modern@ietf.org
References: <00be01d138f8$8bca7080$a35f5180$@ch>  
From: Paul Kyzivat 
Message-ID: <56731C4F.50903@alum.mit.edu>
Date: Thu, 17 Dec 2015 15:34:23 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1450384465; bh=IKAaKGB0hKD/9SNrkzOUYo/lWMM7NU+yH9DE97S1KYE=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=HdNa2I4913SAI7KkP25ys52iOAudgSRSaDnUum1+X1pG21OwGHT8eelHfqATkjMDX hFe/3brrpKaQtVGR2eRyOFBjV03DINaW7yTeOzCci5Vvo+Y/LPdlmpqyO+qTTwqXPQ gQutpZY1D0yVwxc5mBMu2/n6O7bu40mJIXoe4yStSUm4dnHEAUGjEYKz9C3cBZmAoI kKCn+yg/FkF/aPWKdc9G7z1MI0/E4DQpBkJwErGm6Ch+PuMosogp6YwxFd9B4JPV1L bhUetNyZqThAjkGhoHed0ORnNQIArxeE4kUgUZgo+3PRLDhC/kVHFFdRzEdFf3tb8I U9j1JuOgzSrEg==
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 17 Dec 2015 20:34:29 -0000

On 12/17/15 3:00 PM, DOLLY, MARTIN C wrote:
> Tom
>
> That is the point and frustration, shouldn't we have an understanding of the regulatory requirements before blindly defining protocol?

ISTM there is a chicken/egg problem here.

Too often legislators and regulators make up regulations that can't be 
implemented. (Especially right now.) At the same time, they are likely 
not to realize what used to be infeasible would now would be feasible if 
regulations allowed.

It seems like it ought to be easier to get good regulations if you can 
show something concrete to the regulators.

After all, they are now bought in to moving to an all-IP telephone 
system. We didn't wait for that regulation before developing SIP.

	Thanks,
	Paul

> Martin C Dolly
> Lead Member of Technical Staff
> Core & Government/Regulatory Standards
> AT&T
> Cell: 609-903-3360
> Email: md3135@att.com
>
>> On Dec 17, 2015, at 2:49 PM, McGarry, Tom  wrote:
>>
>> What's being designed are tools.  It is up to others, e.g., regulators,
>> authorities, to decide how or whether to use those tools.  That's where
>> the policy gets created.
>>
>> I know it has been controversial to suggest a tool (process) that would
>> allow a consumer to acquire a telephone number directly, rather than thru
>> a service provider.  The most common identifier on the Internet, domain
>> names, uses this model.  We're discussing identifiers, telephone numbers,
>> on IP networks.  It would be irresponsible and backward looking not to
>> account for this possibility.
>>
>> The WG also includes the current process for number allocation, where
>> service providers acquire the numbers and they then in turn allocate
>> numbers to consumers.
>>
>> Entities that decide numbering policies can choose which tools they do and
>> do not want to use.  That is where policies and regulations are created.
>>
>> I know some people on this list refuse to believe this, not matter how
>> often it is said.  But those are the facts.
>>
>>
>>
>>
>>> On 12/17/15 1:27 PM, "Richard Hill"  wrote:
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Adam Roach [mailto:adam@nostrum.com]
>>>> Sent: Thursday, December 17, 2015 19:12
>>>> To: Richard Hill; 'Brian Rosen'; 'Gorman, Pierce A [CTO]'
>>>> Cc: 'Richard Shockey'; 'Alissa Cooper'; 'Steve Donovan';
>>>> modern@ietf.org
>>>> Subject: Re: [Modern] Problem statement draft as working group document
>>>>
>>>>> On 12/17/15 12:07, Richard Hill wrote:
>>>>> Can you (or somebody else) explain to me how processes (which might
>>>> have regulatory implications) regarding assignment of E.164 numbers
>>>> fall within the expertise of the IETF?
>>>>>
>>>>> Or have I misunderstood the scope of the work of this group?
>>>>
>>>> You have misunderstood the scope of the entire IETF. We design network
>>>> protocols. We are not part of any regulatory bodies. What those bodies
>>>> choose to do is entirely in their purview.
>>>
>>>
>>> Are you implying that the IETF can design a protocol without any
>>> reference whatsoever to whether it might violate existing laws and
>>> regulations?
>>>
>>>>
>>>> /a
>>>
>>> _______________________________________________
>>> Modern mailing list
>>> Modern@ietf.org
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_
>>> listinfo_modern&d=CwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLext
>>> Z1ooNcfp01IYIaVqsORjI&m=ozfZfjKsWcLVXeIljVVsmxlsctjUYK9cpOGjPZWtBkw&s=LPGP
>>> t7cTP8zbe-1ZBrkEgho_MZXUC-S7QX5pGaOvL0U&e=
>>
>> _______________________________________________
>> Modern mailing list
>> Modern@ietf.org
>> https://www.ietf.org/mailman/listinfo/modern
>
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern
>


From nobody Thu Dec 17 13:17: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 EDBAB1B308F for ; Thu, 17 Dec 2015 13:17:48 -0800 (PST)
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 e-M7ZT8k0n_L for ; Thu, 17 Dec 2015 13:17:46 -0800 (PST)
Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 05D7A1B30B8 for ; Thu, 17 Dec 2015 13:17:45 -0800 (PST)
Received: (qmail 26331 invoked by uid 0); 17 Dec 2015 21:17:44 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy4.mail.unifiedlayer.com with SMTP; 17 Dec 2015 21:17:44 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with  id ukxf1r00Q1MNPNq01kxiDm; Thu, 17 Dec 2015 13:57:43 -0700
X-Authority-Analysis: v=2.1 cv=dqRIVTQ4 c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=0BRvPPsJEo4A:10 a=wUQvQvOEmiQA:10 a=jqBRFv0mrdUA:10 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=hGBaWAWWAAAA:8 a=Z80JlwQ0AAAA:8 a=RpNjiQI2AAAA:8 a=GZhwznHhEo8xKluG5o4A:9 a=OB9w4avawgaxto_w:21 a=JX4wrHlUMT8ZpY_y:21 a=QEXdDO2ut3YA:10 a=qM39cor4HRgA:10 a=K2lU_Ab98eoA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us;  s=default;  h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=Dary++U0H8TVdtI8IocZJGvpVAZBy/KKg7EKPIh1Sx8=;  b=b90pPltcmccKv2e8O25OimoPCHgRltLjB4MxxyFp4HS5XDXof1lz6K5ewiPewkCmdhb2nHj60CsBQT4jnKjoWEz1PTE0Q3VaZLlJxbx6UUd8ga5EF/Rt4JaF1PUOLsqg;
Received: from [50.241.241.5] (port=63992 helo=[172.20.2.220]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1a9fcK-0008DZ-KS; Thu, 17 Dec 2015 13:57:40 -0700
User-Agent: Microsoft-MacOutlook/0.0.0.151105
Date: Thu, 17 Dec 2015 15:57:33 -0500
From: Richard Shockey 
To: Paul Kyzivat , 
Message-ID: 
Thread-Topic: [Modern] Problem statement draft as working group document
References: <00be01d138f8$8bca7080$a35f5180$@ch>   <56731C4F.50903@alum.mit.edu>
In-Reply-To: <56731C4F.50903@alum.mit.edu>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 50.241.241.5 authed with richard+shockey.us}
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 17 Dec 2015 21:17:49 -0000

On 12/17/15, 3:34 PM, "Modern on behalf of Paul Kyzivat"  wrote:

>On 12/17/15 3:00 PM, DOLLY, MARTIN C wrote:
>> Tom
>>
>> That is the point and frustration, shouldn't we have an understanding of=
 the regulatory requirements before blindly defining protocol?
>
>ISTM there is a chicken/egg problem here.
>
>Too often legislators and regulators make up regulations that can't be=20
>implemented. (Especially right now.) At the same time, they are likely=20
>not to realize what used to be infeasible would now would be feasible if=20
>regulations allowed.


RS>  Paul the regulators know what is technically feasible.  Its just in th=
e universe of problems I=E2=80=99m personally aware of this is still #164.  Compar=
ed to dealing with caller ID spoofing robocalls or implementing national geo=
graphic number portability this is beyond trivial. No one has proved there i=
s a problem here.  Far from it the proponents of this proposition are enteri=
ng the political arena that I and others still have the scars from. At some =
point in time it is an obligation for adults to keep children from wildly ru=
nning amuck in the store.=20

There are two propositions here.  First the concept of restructuring number=
 administration and two the use of highly distributed and synchronized datab=
ases.  My strong objections here is the idea pf putting the cart before the =
horse. We might not be having this conversation if the use case were some ot=
her form of metadata surrounding E.164 numbers which actually might deploy a=
nd then building on success migrate to other types of numbering administrati=
on.=20


>
>It seems like it ought to be easier to get good regulations if you can=20
>show something concrete to the regulators.

RS> Depends on the administration.  In any event that is what open source p=
rojects are for.=20


>
>After all, they are now bought in to moving to an all-IP telephone=20
>system. We didn't wait for that regulation before developing SIP.

RS > Again a false tautology.=20


>
>	Thanks,
>	Paul
>
>> Martin C Dolly
>> Lead Member of Technical Staff
>> Core & Government/Regulatory Standards
>> AT&T
>> Cell: 609-903-3360
>> Email: md3135@att.com
>>
>>> On Dec 17, 2015, at 2:49 PM, McGarry, Tom  wro=
te:
>>>
>>> What's being designed are tools.  It is up to others, e.g., regulators,
>>> authorities, to decide how or whether to use those tools.  That's where
>>> the policy gets created.
>>>
>>> I know it has been controversial to suggest a tool (process) that would
>>> allow a consumer to acquire a telephone number directly, rather than th=
ru
>>> a service provider.  The most common identifier on the Internet, domain
>>> names, uses this model.  We're discussing identifiers, telephone number=
s,
>>> on IP networks.  It would be irresponsible and backward looking not to
>>> account for this possibility.
>>>
>>> The WG also includes the current process for number allocation, where
>>> service providers acquire the numbers and they then in turn allocate
>>> numbers to consumers.
>>>
>>> Entities that decide numbering policies can choose which tools they do =
and
>>> do not want to use.  That is where policies and regulations are created=
.
>>>
>>> I know some people on this list refuse to believe this, not matter how
>>> often it is said.  But those are the facts.
>>>
>>>
>>>
>>>
>>>> On 12/17/15 1:27 PM, "Richard Hill"  wrote:
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Adam Roach [mailto:adam@nostrum.com]
>>>>> Sent: Thursday, December 17, 2015 19:12
>>>>> To: Richard Hill; 'Brian Rosen'; 'Gorman, Pierce A [CTO]'
>>>>> Cc: 'Richard Shockey'; 'Alissa Cooper'; 'Steve Donovan';
>>>>> modern@ietf.org
>>>>> Subject: Re: [Modern] Problem statement draft as working group docume=
nt
>>>>>
>>>>>> On 12/17/15 12:07, Richard Hill wrote:
>>>>>> Can you (or somebody else) explain to me how processes (which might
>>>>> have regulatory implications) regarding assignment of E.164 numbers
>>>>> fall within the expertise of the IETF?
>>>>>>
>>>>>> Or have I misunderstood the scope of the work of this group?
>>>>>
>>>>> You have misunderstood the scope of the entire IETF. We design networ=
k
>>>>> protocols. We are not part of any regulatory bodies. What those bodie=
s
>>>>> choose to do is entirely in their purview.
>>>>
>>>>
>>>> Are you implying that the IETF can design a protocol without any
>>>> reference whatsoever to whether it might violate existing laws and
>>>> regulations?
>>>>
>>>>>
>>>>> /a
>>>>
>>>> _______________________________________________
>>>> Modern mailing list
>>>> Modern@ietf.org
>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail=
man_
>>>> listinfo_modern&d=3DCwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeIDc=
Lext
>>>> Z1ooNcfp01IYIaVqsORjI&m=3DozfZfjKsWcLVXeIljVVsmxlsctjUYK9cpOGjPZWtBkw&s=3D=
LPGP
>>>> t7cTP8zbe-1ZBrkEgho_MZXUC-S7QX5pGaOvL0U&e=3D
>>>
>>> _______________________________________________
>>> Modern mailing list
>>> Modern@ietf.org
>>> https://www.ietf.org/mailman/listinfo/modern
>>
>> _______________________________________________
>> Modern mailing list
>> Modern@ietf.org
>> https://www.ietf.org/mailman/listinfo/modern
>>
>
>_______________________________________________
>Modern mailing list
>Modern@ietf.org
>https://www.ietf.org/mailman/listinfo/modern


From nobody Thu Dec 17 13:50:33 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E041B30CD for ; Thu, 17 Dec 2015 13:50:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bTNJelGgrmL for ; Thu, 17 Dec 2015 13:50:27 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 C6B041A89A0 for ; Thu, 17 Dec 2015 13:50:27 -0800 (PST)
Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id tBHLnqjM036397; Thu, 17 Dec 2015 16:50:27 -0500
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 1ytsjgn9ft-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);  Thu, 17 Dec 2015 16:50:27 -0500
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 tBHLoObj004883; Thu, 17 Dec 2015 16:50:25 -0500
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 tBHLoFX8004757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 17 Dec 2015 16:50:20 -0500
Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Thu, 17 Dec 2015 21:49:55 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.78]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0248.002; Thu, 17 Dec 2015 16:49:55 -0500
From: "DOLLY, MARTIN C" 
To: "McGarry, Tom" 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHROEiYt9tG2eQFXECnCpoLN3xbKp7OlCAAgADTIpCAAFmaAIAADhaAgAABNICAAAQrAIAAFuCA//+vSaiAAFmJgP//xGFA
Date: Thu, 17 Dec 2015 21:49:54 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.193.27]
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-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-12-17_03:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310007 definitions=main-1512170355
Archived-At: 
Cc: "modern@ietf.org" 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 17 Dec 2015 21:50:30 -0000

That is the problem my friend. And note this is USA issue, so those that as=
k why IETF are involved are correct.=20

I believe the IETF is good for parts but not the whole solution.

Let us stop dancing around the naked emperor...

-----Original Message-----
From: McGarry, Tom [mailto:Tom.McGarry@neustar.biz]=20
Sent: Thursday, December 17, 2015 3:21 PM
To: DOLLY, MARTIN C 
Cc: modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

No, that would get us involved with regulations and policies.  Our role is =
to understand the environment from a technology and process perspective, an=
ticipate needs (e.g., perhaps including a more Internet-like model) and cre=
ate solutions.  It's up to others to choose what they will and will not use=
. =20

On 12/17/15 3:00 PM, "DOLLY, MARTIN C"  wrote:

>Tom
>
>That is the point and frustration, shouldn't we have an understanding=20
>of the regulatory requirements before blindly defining protocol?
>
>Martin C Dolly
>Lead Member of Technical Staff
>Core & Government/Regulatory Standards
>AT&T
>Cell: 609-903-3360
>Email: md3135@att.com
>
>> On Dec 17, 2015, at 2:49 PM, McGarry, Tom 
>>wrote:
>>=20
>> What's being designed are tools.  It is up to others, e.g.,=20
>> regulators, authorities, to decide how or whether to use those tools. =20
>> That's where the policy gets created.
>>=20
>> I know it has been controversial to suggest a tool (process) that=20
>>would  allow a consumer to acquire a telephone number directly, rather=20
>>than thru  a service provider.  The most common identifier on the=20
>>Internet, domain  names, uses this model.  We're discussing=20
>>identifiers, telephone numbers,  on IP networks.  It would be=20
>>irresponsible and backward looking not to  account for this=20
>>possibility.
>>=20
>> The WG also includes the current process for number allocation, where=20
>> service providers acquire the numbers and they then in turn allocate=20
>> numbers to consumers.
>>=20
>> Entities that decide numbering policies can choose which tools they=20
>>do and  do not want to use.  That is where policies and regulations=20
>>are created.
>>=20
>> I know some people on this list refuse to believe this, not matter=20
>> how often it is said.  But those are the facts.
>>=20
>>=20
>>=20
>>=20
>>> On 12/17/15 1:27 PM, "Richard Hill"  wrote:
>>>=20
>>>=20
>>>=20
>>>> -----Original Message-----
>>>> From: Adam Roach [mailto:adam@nostrum.com]
>>>> Sent: Thursday, December 17, 2015 19:12
>>>> To: Richard Hill; 'Brian Rosen'; 'Gorman, Pierce A [CTO]'
>>>> Cc: 'Richard Shockey'; 'Alissa Cooper'; 'Steve Donovan'; =20
>>>>modern@ietf.org
>>>> Subject: Re: [Modern] Problem statement draft as working group=20
>>>>document
>>>>=20
>>>>> On 12/17/15 12:07, Richard Hill wrote:
>>>>> Can you (or somebody else) explain to me how processes (which=20
>>>>> might
>>>> have regulatory implications) regarding assignment of E.164 numbers=20
>>>> fall within the expertise of the IETF?
>>>>>=20
>>>>> Or have I misunderstood the scope of the work of this group?
>>>>=20
>>>> You have misunderstood the scope of the entire IETF. We design=20
>>>> network protocols. We are not part of any regulatory bodies. What=20
>>>> those bodies choose to do is entirely in their purview.
>>>=20
>>>=20
>>> Are you implying that the IETF can design a protocol without any=20
>>> reference whatsoever to whether it might violate existing laws and=20
>>> regulations?
>>>=20
>>>>=20
>>>> /a
>>>=20
>>> _______________________________________________
>>> Modern mailing list
>>> Modern@ietf.org
>>>=20
>>>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai
>>>lma
>>>n_
>>>=20
>>>listinfo_modern&d=3DCwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve=
eID
>>>cLe
>>>xt
>>>=20
>>>Z1ooNcfp01IYIaVqsORjI&m=3DozfZfjKsWcLVXeIljVVsmxlsctjUYK9cpOGjPZWtBkw&s
>>>=3DLP
>>>GP
>>> t7cTP8zbe-1ZBrkEgho_MZXUC-S7QX5pGaOvL0U&e=3D
>>=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=3DCwIFAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve=
eID
>>cLe=20
>>xtZ1ooNcfp01IYIaVqsORjI&m=3D6k6xBxpm7dn7KBeEKiMOttP4N0RYgrEx_jL-ZEio3tc&
>>s=3DR wfQDsbB7PHQvmP4WR0eqfXpetHM9q0n4Pr5CuIXEVU&e=3D


From nobody Thu Dec 17 15:04: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 480E41B310C for ; Thu, 17 Dec 2015 15:04:56 -0800 (PST)
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 5HoCjvxZtFT3 for ; Thu, 17 Dec 2015 15:04:54 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D31341B310B for ; Thu, 17 Dec 2015 15:04:53 -0800 (PST)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 4050520474 for ; Thu, 17 Dec 2015 18:04:53 -0500 (EST)
Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 17 Dec 2015 18:04:53 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=PVnec82EyUcOsy+RZo6JACuuvdk=; b=2SkRdc CUNR9/Oy4gUJEKlqj1sy8XwoHoKvzQcUOm0/eUGHLMD034sfCzUag4WDxYBlPFCK iU/8TT2g3TLo4ktAzYLkWjfLeuvDdarjpqjIeqJ7spVvZH6WrQstP/V3aBUIS3xG ooJj0Xv16izLS4ab03BOf+3XI8LTFn/bINwuU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=PVnec82EyUcOsy+ RZo6JACuuvdk=; b=PVsMoPrJucjKkVpmGHNEJlJqEEtHvlUEvBpffSqZGnroVUT 9K7EFaTpkx7J1hu61uLCSJFevYkjwzZnKEYsXJEbholtxjTlDkXyK1LG49RcVv8Q gVQ4LO8rURTWDSPSfjlptrOmKoLlho/Z36CgoXipNR8In5Hw8Bk46zdIDqvU=
X-Sasl-enc: vBFWHA44zS8h6ZWiu+u6pbkRwzaMIru5aCEh1GwUczIt 1450393492
Received: from [10.24.126.103] (unknown [128.107.241.168]) by mail.messagingengine.com (Postfix) with ESMTPA id 086E0680118; Thu, 17 Dec 2015 18:04:51 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Alissa Cooper 
In-Reply-To: 
Date: Thu, 17 Dec 2015 18:04:46 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   
To: "DOLLY, MARTIN C" 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: "modern@ietf.org" , "McGarry, Tom" 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 17 Dec 2015 23:04:56 -0000

The IETF is an open organization with global participation. Any =
mechanisms defined in this or any other WG need to be flexible enough to =
accommodate requirements that exist or may be established in a variety =
of jurisdictions. Individual participants may concern themselves only =
with their home jurisdictions, but that does not eliminate the need to =
produce tools that can be used across jurisdictions.=20

Alissa

> On Dec 17, 2015, at 4:49 PM, DOLLY, MARTIN C  wrote:
>=20
> That is the problem my friend. And note this is USA issue, so those =
that ask why IETF are involved are correct.
>=20
> I believe the IETF is good for parts but not the whole solution.
>=20
> Let us stop dancing around the naked emperor...
>=20
> -----Original Message-----
> From: McGarry, Tom [mailto:Tom.McGarry@neustar.biz]=20
> Sent: Thursday, December 17, 2015 3:21 PM
> To: DOLLY, MARTIN C 
> Cc: modern@ietf.org
> Subject: Re: [Modern] Problem statement draft as working group =
document
>=20
> No, that would get us involved with regulations and policies.  Our =
role is to understand the environment from a technology and process =
perspective, anticipate needs (e.g., perhaps including a more =
Internet-like model) and create solutions.  It's up to others to choose =
what they will and will not use. =20
>=20
> On 12/17/15 3:00 PM, "DOLLY, MARTIN C"  wrote:
>=20
>> Tom
>>=20
>> That is the point and frustration, shouldn't we have an understanding=20=

>> of the regulatory requirements before blindly defining protocol?
>>=20
>> Martin C Dolly
>> Lead Member of Technical Staff
>> Core & Government/Regulatory Standards
>> AT&T
>> Cell: 609-903-3360
>> Email: md3135@att.com
>>=20
>>> On Dec 17, 2015, at 2:49 PM, McGarry, Tom 
>>> wrote:
>>>=20
>>> What's being designed are tools.  It is up to others, e.g.,=20
>>> regulators, authorities, to decide how or whether to use those =
tools. =20
>>> That's where the policy gets created.
>>>=20
>>> I know it has been controversial to suggest a tool (process) that=20
>>> would  allow a consumer to acquire a telephone number directly, =
rather=20
>>> than thru  a service provider.  The most common identifier on the=20
>>> Internet, domain  names, uses this model.  We're discussing=20
>>> identifiers, telephone numbers,  on IP networks.  It would be=20
>>> irresponsible and backward looking not to  account for this=20
>>> possibility.
>>>=20
>>> The WG also includes the current process for number allocation, =
where=20
>>> service providers acquire the numbers and they then in turn allocate=20=

>>> numbers to consumers.
>>>=20
>>> Entities that decide numbering policies can choose which tools they=20=

>>> do and  do not want to use.  That is where policies and regulations=20=

>>> are created.
>>>=20
>>> I know some people on this list refuse to believe this, not matter=20=

>>> how often it is said.  But those are the facts.
>>>=20
>>>=20
>>>=20
>>>=20
>>>> On 12/17/15 1:27 PM, "Richard Hill"  wrote:
>>>>=20
>>>>=20
>>>>=20
>>>>> -----Original Message-----
>>>>> From: Adam Roach [mailto:adam@nostrum.com]
>>>>> Sent: Thursday, December 17, 2015 19:12
>>>>> To: Richard Hill; 'Brian Rosen'; 'Gorman, Pierce A [CTO]'
>>>>> Cc: 'Richard Shockey'; 'Alissa Cooper'; 'Steve Donovan'; =20
>>>>> modern@ietf.org
>>>>> Subject: Re: [Modern] Problem statement draft as working group=20
>>>>> document
>>>>>=20
>>>>>> On 12/17/15 12:07, Richard Hill wrote:
>>>>>> Can you (or somebody else) explain to me how processes (which=20
>>>>>> might
>>>>> have regulatory implications) regarding assignment of E.164 =
numbers=20
>>>>> fall within the expertise of the IETF?
>>>>>>=20
>>>>>> Or have I misunderstood the scope of the work of this group?
>>>>>=20
>>>>> You have misunderstood the scope of the entire IETF. We design=20
>>>>> network protocols. We are not part of any regulatory bodies. What=20=

>>>>> those bodies choose to do is entirely in their purview.
>>>>=20
>>>>=20
>>>> Are you implying that the IETF can design a protocol without any=20
>>>> reference whatsoever to whether it might violate existing laws and=20=

>>>> regulations?
>>>>=20
>>>>>=20
>>>>> /a
>>>>=20
>>>> _______________________________________________
>>>> Modern mailing list
>>>> Modern@ietf.org
>>>>=20
>>>> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai
>>>> lma
>>>> n_
>>>>=20
>>>> =
listinfo_modern&d=3DCwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI=
D
>>>> cLe
>>>> xt
>>>>=20
>>>> =
Z1ooNcfp01IYIaVqsORjI&m=3DozfZfjKsWcLVXeIljVVsmxlsctjUYK9cpOGjPZWtBkw&s
>>>> =3DLP
>>>> GP
>>>> t7cTP8zbe-1ZBrkEgho_MZXUC-S7QX5pGaOvL0U&e=3D
>>>=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=3DCwIFAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufvee=
ID
>>> cLe=20
>>> =
xtZ1ooNcfp01IYIaVqsORjI&m=3D6k6xBxpm7dn7KBeEKiMOttP4N0RYgrEx_jL-ZEio3tc&
>>> s=3DR wfQDsbB7PHQvmP4WR0eqfXpetHM9q0n4Pr5CuIXEVU&e=3D
>=20
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern


From nobody Thu Dec 17 15:28:25 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5EE41B3123 for ; Thu, 17 Dec 2015 15:28:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iu5OArIqHyds for ; Thu, 17 Dec 2015 15:28:21 -0800 (PST)
Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 99FF91B311A for ; Thu, 17 Dec 2015 15:28:21 -0800 (PST)
Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id tBHNOC5x014015; Thu, 17 Dec 2015 18:28:15 -0500
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049458.ppops.net-00191d01. with ESMTP id 1yu0w3a4es-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);  Thu, 17 Dec 2015 18:28:14 -0500
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 tBHNSCNR000443; Thu, 17 Dec 2015 18:28:13 -0500
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 tBHNS0A9000307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 17 Dec 2015 18:28:07 -0500
Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Thu, 17 Dec 2015 23:27:46 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.78]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0248.002; Thu, 17 Dec 2015 18:27:45 -0500
From: "DOLLY, MARTIN C" 
To: Alissa Cooper 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHROEiYt9tG2eQFXECnCpoLN3xbKp7OlCAAgADTIpCAAFmaAIAADhaAgAABNICAAAQrAIAAFuCA//+vSaiAAFmJgP//xGFAgABpgQD//7Ka5Q==
Date: Thu, 17 Dec 2015 23:27:45 +0000
Message-ID: <0F8F091A-7255-4781-81A3-48400BC670A1@att.com>
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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-12-17_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310007 definitions=main-1512170384
Archived-At: 
Cc: "modern@ietf.org" , "McGarry, Tom" 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 17 Dec 2015 23:28:25 -0000

Alissa

Please explain which country outside the USA this is being driven by?

I asked all my 3GPP colleagues, and the answer is none.=20

Look at the carrier participation on the list=20

If it looks like a duck, maybe it is a duck

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards=20
AT&T
Cell: 609-903-3360
Email: md3135@att.com

> On Dec 17, 2015, at 6:05 PM, Alissa Cooper  wrote:
>=20
> The IETF is an open organization with global participation. Any mechanism=
s defined in this or any other WG need to be flexible enough to accommodate=
 requirements that exist or may be established in a variety of jurisdiction=
s. Individual participants may concern themselves only with their home juri=
sdictions, but that does not eliminate the need to produce tools that can b=
e used across jurisdictions.=20
>=20
> Alissa
>=20
>> On Dec 17, 2015, at 4:49 PM, DOLLY, MARTIN C  wrote:
>>=20
>> That is the problem my friend. And note this is USA issue, so those that=
 ask why IETF are involved are correct.
>>=20
>> I believe the IETF is good for parts but not the whole solution.
>>=20
>> Let us stop dancing around the naked emperor...
>>=20
>> -----Original Message-----
>> From: McGarry, Tom [mailto:Tom.McGarry@neustar.biz]=20
>> Sent: Thursday, December 17, 2015 3:21 PM
>> To: DOLLY, MARTIN C 
>> Cc: modern@ietf.org
>> Subject: Re: [Modern] Problem statement draft as working group document
>>=20
>> No, that would get us involved with regulations and policies.  Our role =
is to understand the environment from a technology and process perspective,=
 anticipate needs (e.g., perhaps including a more Internet-like model) and =
create solutions.  It's up to others to choose what they will and will not =
use. =20
>>=20
>>> On 12/17/15 3:00 PM, "DOLLY, MARTIN C"  wrote:
>>>=20
>>> Tom
>>>=20
>>> That is the point and frustration, shouldn't we have an understanding=20
>>> of the regulatory requirements before blindly defining protocol?
>>>=20
>>> Martin C Dolly
>>> Lead Member of Technical Staff
>>> Core & Government/Regulatory Standards
>>> AT&T
>>> Cell: 609-903-3360
>>> Email: md3135@att.com
>>>=20
>>>> On Dec 17, 2015, at 2:49 PM, McGarry, Tom 
>>>> wrote:
>>>>=20
>>>> What's being designed are tools.  It is up to others, e.g.,=20
>>>> regulators, authorities, to decide how or whether to use those tools. =
=20
>>>> That's where the policy gets created.
>>>>=20
>>>> I know it has been controversial to suggest a tool (process) that=20
>>>> would  allow a consumer to acquire a telephone number directly, rather=
=20
>>>> than thru  a service provider.  The most common identifier on the=20
>>>> Internet, domain  names, uses this model.  We're discussing=20
>>>> identifiers, telephone numbers,  on IP networks.  It would be=20
>>>> irresponsible and backward looking not to  account for this=20
>>>> possibility.
>>>>=20
>>>> The WG also includes the current process for number allocation, where=
=20
>>>> service providers acquire the numbers and they then in turn allocate=20
>>>> numbers to consumers.
>>>>=20
>>>> Entities that decide numbering policies can choose which tools they=20
>>>> do and  do not want to use.  That is where policies and regulations=20
>>>> are created.
>>>>=20
>>>> I know some people on this list refuse to believe this, not matter=20
>>>> how often it is said.  But those are the facts.
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>> On 12/17/15 1:27 PM, "Richard Hill"  wrote:
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: Adam Roach [mailto:adam@nostrum.com]
>>>>>> Sent: Thursday, December 17, 2015 19:12
>>>>>> To: Richard Hill; 'Brian Rosen'; 'Gorman, Pierce A [CTO]'
>>>>>> Cc: 'Richard Shockey'; 'Alissa Cooper'; 'Steve Donovan'; =20
>>>>>> modern@ietf.org
>>>>>> Subject: Re: [Modern] Problem statement draft as working group=20
>>>>>> document
>>>>>>=20
>>>>>>> On 12/17/15 12:07, Richard Hill wrote:
>>>>>>> Can you (or somebody else) explain to me how processes (which=20
>>>>>>> might
>>>>>> have regulatory implications) regarding assignment of E.164 numbers=
=20
>>>>>> fall within the expertise of the IETF?
>>>>>>>=20
>>>>>>> Or have I misunderstood the scope of the work of this group?
>>>>>>=20
>>>>>> You have misunderstood the scope of the entire IETF. We design=20
>>>>>> network protocols. We are not part of any regulatory bodies. What=20
>>>>>> those bodies choose to do is entirely in their purview.
>>>>>=20
>>>>>=20
>>>>> Are you implying that the IETF can design a protocol without any=20
>>>>> reference whatsoever to whether it might violate existing laws and=20
>>>>> regulations?
>>>>>=20
>>>>>>=20
>>>>>> /a
>>>>>=20
>>>>> _______________________________________________
>>>>> Modern mailing list
>>>>> Modern@ietf.org
>>>>>=20
>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_m=
ai
>>>>> lma
>>>>> n_
>>>>>=20
>>>>> listinfo_modern&d=3DCwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hu=
fveeID
>>>>> cLe
>>>>> xt
>>>>>=20
>>>>> Z1ooNcfp01IYIaVqsORjI&m=3DozfZfjKsWcLVXeIljVVsmxlsctjUYK9cpOGjPZWtBkw=
&s
>>>>> =3DLP
>>>>> GP
>>>>> t7cTP8zbe-1ZBrkEgho_MZXUC-S7QX5pGaOvL0U&e=3D
>>>>=20
>>>> _______________________________________________
>>>> Modern mailing list
>>>> Modern@ietf.org
>>>>=20
>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma=
il
>>>> man=20
>>>> _listinfo_modern&d=3DCwIFAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hu=
fveeID
>>>> cLe=20
>>>> xtZ1ooNcfp01IYIaVqsORjI&m=3D6k6xBxpm7dn7KBeEKiMOttP4N0RYgrEx_jL-ZEio3t=
c&
>>>> s=3DR wfQDsbB7PHQvmP4WR0eqfXpetHM9q0n4Pr5CuIXEVU&e=3D
>>=20
>> _______________________________________________
>> Modern mailing list
>> Modern@ietf.org
>> https://www.ietf.org/mailman/listinfo/modern
>=20


From nobody Thu Dec 17 16:15: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 E3ADE1B312C for ; Thu, 17 Dec 2015 16:15:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 6c7hI8WElIlV for ; Thu, 17 Dec 2015 16:15:12 -0800 (PST)
Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (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 DCB771B313A for ; Thu, 17 Dec 2015 16:15:11 -0800 (PST)
Received: by mail-qg0-x22a.google.com with SMTP id k90so42238163qge.0 for ; Thu, 17 Dec 2015 16:15:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=amzXgvqaXBdONjXdoHQgbTw5d6fAi4RwRHQgGbK9USc=; b=hg+85pyJterG3jE2zcce4n7Xo5KYgn2cnm6NdvkOMiGIpoj2SDaihVSeInjcYj5grA Sh8tI9lERhsbJGEDjcairznupa+Vgc+lsY5ECILwkwfFft/KJ30gR/yWN4S/CU7SbiXK qEhDbB/iGsPwHZvoTvclgZSZZoehoPYa7KlMOCII/QICgTQCBphw3DYFSJfwz/6xUAU0 YLf0SXvxSip6H8TaEp2GMG99NjpdcbdYstoguQh0adeU7tTvHkQLgJQdKpENSSNLkaNN SCMIiYjqfpGq7xtY3gv93w7jPvziqv2765a9nFUoC8jj31dzjzqXMs9N83BibgP2IKGx 4BJw==
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=amzXgvqaXBdONjXdoHQgbTw5d6fAi4RwRHQgGbK9USc=; b=B/2vEh1lsUcdPwow2Tj06mjUcY3avaXFxcmeKmLTLHHxmoc4BYJxQXPNJ6ZIo2eQwE o9GhMPD1SjbAgXsRtK2wo4heWZFcQUV9plLdSa56/slpnlqoR3wOXM5Alh/Bm9hck6qo YHjs7hyfW2jd1yJgY4EXbZZejZikU9YyuzTxulX0oygy/duw75wvSqCsJthJiI4Y4mIL Q1WG6mzBYaKg+1OKvm1NRckq8x8bJkLfR15XR5lZSI/vcYCYD7qNoe9zmoauCv1DhQng x7Rh5fMjOPZi28mIoRpVNDX3/kgF6SOPQnGDxDEa9MVz+E+eTB92XuuaM5LfRzdMFi7/ aR4A==
X-Gm-Message-State: ALoCoQmaVA7UgqZ61k+3DaH5aOrxlnqAGx1Eshjcuw+cjYwXw3k9YEA/xANVFaK2coj6R9IedAWuHvYbGBLgV3P8NOgi0KO2Lg==
X-Received: by 10.140.93.77 with SMTP id c71mr1000877qge.46.1450397711116; Thu, 17 Dec 2015 16:15:11 -0800 (PST)
Received: from [10.33.192.14] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id e11sm5728406qkb.39.2015.12.17.16.15.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 17 Dec 2015 16:15:09 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Brian Rosen 
In-Reply-To: <0F8F091A-7255-4781-81A3-48400BC670A1@att.com>
Date: Thu, 17 Dec 2015 19:15:06 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:     <0F8F091A-7255-4781-81A3-48400BC670A1@att.com>
To: "DOLLY, MARTIN C" 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "modern@ietf.org" , Alissa Cooper , Tom McGarry 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 18 Dec 2015 00:15:15 -0000

I=E2=80=99ve talked to a couple of regulators beyond the U.S. ones.  =
Some EU, some smaller nations.  As you know, a number of regulators send =
folks to IETF meetings.  They are VERY interested.  I wouldn=E2=80=99t =
say anyone is committed, just interested.

Brian

> On Dec 17, 2015, at 6:27 PM, DOLLY, MARTIN C  wrote:
>=20
> Alissa
>=20
> Please explain which country outside the USA this is being driven by?
>=20
> I asked all my 3GPP colleagues, and the answer is none.=20
>=20
> Look at the carrier participation on the list=20
>=20
> If it looks like a duck, maybe it is a duck
>=20
> Martin C Dolly
> Lead Member of Technical Staff
> Core & Government/Regulatory Standards=20
> AT&T
> Cell: 609-903-3360
> Email: md3135@att.com
>=20
>> On Dec 17, 2015, at 6:05 PM, Alissa Cooper  wrote:
>>=20
>> The IETF is an open organization with global participation. Any =
mechanisms defined in this or any other WG need to be flexible enough to =
accommodate requirements that exist or may be established in a variety =
of jurisdictions. Individual participants may concern themselves only =
with their home jurisdictions, but that does not eliminate the need to =
produce tools that can be used across jurisdictions.=20
>>=20
>> Alissa
>>=20
>>> On Dec 17, 2015, at 4:49 PM, DOLLY, MARTIN C  wrote:
>>>=20
>>> That is the problem my friend. And note this is USA issue, so those =
that ask why IETF are involved are correct.
>>>=20
>>> I believe the IETF is good for parts but not the whole solution.
>>>=20
>>> Let us stop dancing around the naked emperor...
>>>=20
>>> -----Original Message-----
>>> From: McGarry, Tom [mailto:Tom.McGarry@neustar.biz]=20
>>> Sent: Thursday, December 17, 2015 3:21 PM
>>> To: DOLLY, MARTIN C 
>>> Cc: modern@ietf.org
>>> Subject: Re: [Modern] Problem statement draft as working group =
document
>>>=20
>>> No, that would get us involved with regulations and policies.  Our =
role is to understand the environment from a technology and process =
perspective, anticipate needs (e.g., perhaps including a more =
Internet-like model) and create solutions.  It's up to others to choose =
what they will and will not use. =20
>>>=20
>>>> On 12/17/15 3:00 PM, "DOLLY, MARTIN C"  wrote:
>>>>=20
>>>> Tom
>>>>=20
>>>> That is the point and frustration, shouldn't we have an =
understanding=20
>>>> of the regulatory requirements before blindly defining protocol?
>>>>=20
>>>> Martin C Dolly
>>>> Lead Member of Technical Staff
>>>> Core & Government/Regulatory Standards
>>>> AT&T
>>>> Cell: 609-903-3360
>>>> Email: md3135@att.com
>>>>=20
>>>>> On Dec 17, 2015, at 2:49 PM, McGarry, Tom =

>>>>> wrote:
>>>>>=20
>>>>> What's being designed are tools.  It is up to others, e.g.,=20
>>>>> regulators, authorities, to decide how or whether to use those =
tools. =20
>>>>> That's where the policy gets created.
>>>>>=20
>>>>> I know it has been controversial to suggest a tool (process) that=20=

>>>>> would  allow a consumer to acquire a telephone number directly, =
rather=20
>>>>> than thru  a service provider.  The most common identifier on the=20=

>>>>> Internet, domain  names, uses this model.  We're discussing=20
>>>>> identifiers, telephone numbers,  on IP networks.  It would be=20
>>>>> irresponsible and backward looking not to  account for this=20
>>>>> possibility.
>>>>>=20
>>>>> The WG also includes the current process for number allocation, =
where=20
>>>>> service providers acquire the numbers and they then in turn =
allocate=20
>>>>> numbers to consumers.
>>>>>=20
>>>>> Entities that decide numbering policies can choose which tools =
they=20
>>>>> do and  do not want to use.  That is where policies and =
regulations=20
>>>>> are created.
>>>>>=20
>>>>> I know some people on this list refuse to believe this, not matter=20=

>>>>> how often it is said.  But those are the facts.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>> On 12/17/15 1:27 PM, "Richard Hill"  wrote:
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: Adam Roach [mailto:adam@nostrum.com]
>>>>>>> Sent: Thursday, December 17, 2015 19:12
>>>>>>> To: Richard Hill; 'Brian Rosen'; 'Gorman, Pierce A [CTO]'
>>>>>>> Cc: 'Richard Shockey'; 'Alissa Cooper'; 'Steve Donovan'; =20
>>>>>>> modern@ietf.org
>>>>>>> Subject: Re: [Modern] Problem statement draft as working group=20=

>>>>>>> document
>>>>>>>=20
>>>>>>>> On 12/17/15 12:07, Richard Hill wrote:
>>>>>>>> Can you (or somebody else) explain to me how processes (which=20=

>>>>>>>> might
>>>>>>> have regulatory implications) regarding assignment of E.164 =
numbers=20
>>>>>>> fall within the expertise of the IETF?
>>>>>>>>=20
>>>>>>>> Or have I misunderstood the scope of the work of this group?
>>>>>>>=20
>>>>>>> You have misunderstood the scope of the entire IETF. We design=20=

>>>>>>> network protocols. We are not part of any regulatory bodies. =
What=20
>>>>>>> those bodies choose to do is entirely in their purview.
>>>>>>=20
>>>>>>=20
>>>>>> Are you implying that the IETF can design a protocol without any=20=

>>>>>> reference whatsoever to whether it might violate existing laws =
and=20
>>>>>> regulations?
>>>>>>=20
>>>>>>>=20
>>>>>>> /a
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> Modern mailing list
>>>>>> Modern@ietf.org
>>>>>>=20
>>>>>> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai
>>>>>> lma
>>>>>> n_
>>>>>>=20
>>>>>> =
listinfo_modern&d=3DCwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI=
D
>>>>>> cLe
>>>>>> xt
>>>>>>=20
>>>>>> =
Z1ooNcfp01IYIaVqsORjI&m=3DozfZfjKsWcLVXeIljVVsmxlsctjUYK9cpOGjPZWtBkw&s
>>>>>> =3DLP
>>>>>> GP
>>>>>> t7cTP8zbe-1ZBrkEgho_MZXUC-S7QX5pGaOvL0U&e=3D
>>>>>=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=3DCwIFAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufvee=
ID
>>>>> cLe=20
>>>>> =
xtZ1ooNcfp01IYIaVqsORjI&m=3D6k6xBxpm7dn7KBeEKiMOttP4N0RYgrEx_jL-ZEio3tc&
>>>>> s=3DR wfQDsbB7PHQvmP4WR0eqfXpetHM9q0n4Pr5CuIXEVU&e=3D
>>>=20
>>> _______________________________________________
>>> Modern mailing list
>>> Modern@ietf.org
>>> https://www.ietf.org/mailman/listinfo/modern
>>=20
>=20
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern


From nobody Thu Dec 17 17:22: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 5A98D1B31C7 for ; Thu, 17 Dec 2015 17:22:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIcM1TzWWPdQ for ; Thu, 17 Dec 2015 17:22:38 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 1D0B11B31C3 for ; Thu, 17 Dec 2015 17:22:38 -0800 (PST)
Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id tBI1KQ1j015905; Thu, 17 Dec 2015 20:22:35 -0500
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0048589.ppops.net-00191d01. with ESMTP id 1ytsjf6ybf-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);  Thu, 17 Dec 2015 20:22:34 -0500
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 tBI1MXmF032272; Thu, 17 Dec 2015 20:22:33 -0500
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 tBI1MQ4u032214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 17 Dec 2015 20:22:27 -0500
Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 18 Dec 2015 01:22:22 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.78]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0248.002; Thu, 17 Dec 2015 20:22:22 -0500
From: "DOLLY, MARTIN C" 
To: Brian Rosen 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHROEiYt9tG2eQFXECnCpoLN3xbKp7OlCAAgADTIpCAAFmaAIAADhaAgAABNICAAAQrAIAAFuCA//+vSaiAAFmJgP//xGFAgABpgQD//7Ka5QAMIZ4A//+++Io=
Date: Fri, 18 Dec 2015 01:22:21 +0000
Message-ID: <1BD85DAA-9DC4-459F-91E1-A9ACD51F7CEC@att.com>
References:     <0F8F091A-7255-4781-81A3-48400BC670A1@att.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-12-18_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310007 definitions=main-1512180025
Archived-At: 
Cc: "modern@ietf.org" , Alissa Cooper , Tom McGarry 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 18 Dec 2015 01:22:40 -0000

And my conversation with large EU and Asian was they were not, interesting=
=20

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards=20
AT&T
Cell: 609-903-3360
Email: md3135@att.com

> On Dec 17, 2015, at 7:15 PM, Brian Rosen  wrote:
>=20
> I=92ve talked to a couple of regulators beyond the U.S. ones.  Some EU, s=
ome smaller nations.  As you know, a number of regulators send folks to IET=
F meetings.  They are VERY interested.  I wouldn=92t say anyone is committe=
d, just interested.
>=20
> Brian
>=20
>> On Dec 17, 2015, at 6:27 PM, DOLLY, MARTIN C  wrote:
>>=20
>> Alissa
>>=20
>> Please explain which country outside the USA this is being driven by?
>>=20
>> I asked all my 3GPP colleagues, and the answer is none.=20
>>=20
>> Look at the carrier participation on the list=20
>>=20
>> If it looks like a duck, maybe it is a duck
>>=20
>> Martin C Dolly
>> Lead Member of Technical Staff
>> Core & Government/Regulatory Standards=20
>> AT&T
>> Cell: 609-903-3360
>> Email: md3135@att.com
>>=20
>>> On Dec 17, 2015, at 6:05 PM, Alissa Cooper  wrote:
>>>=20
>>> The IETF is an open organization with global participation. Any mechani=
sms defined in this or any other WG need to be flexible enough to accommoda=
te requirements that exist or may be established in a variety of jurisdicti=
ons. Individual participants may concern themselves only with their home ju=
risdictions, but that does not eliminate the need to produce tools that can=
 be used across jurisdictions.=20
>>>=20
>>> Alissa
>>>=20
>>>> On Dec 17, 2015, at 4:49 PM, DOLLY, MARTIN C  wrote:
>>>>=20
>>>> That is the problem my friend. And note this is USA issue, so those th=
at ask why IETF are involved are correct.
>>>>=20
>>>> I believe the IETF is good for parts but not the whole solution.
>>>>=20
>>>> Let us stop dancing around the naked emperor...
>>>>=20
>>>> -----Original Message-----
>>>> From: McGarry, Tom [mailto:Tom.McGarry@neustar.biz]=20
>>>> Sent: Thursday, December 17, 2015 3:21 PM
>>>> To: DOLLY, MARTIN C 
>>>> Cc: modern@ietf.org
>>>> Subject: Re: [Modern] Problem statement draft as working group documen=
t
>>>>=20
>>>> No, that would get us involved with regulations and policies.  Our rol=
e is to understand the environment from a technology and process perspectiv=
e, anticipate needs (e.g., perhaps including a more Internet-like model) an=
d create solutions.  It's up to others to choose what they will and will no=
t use. =20
>>>>=20
>>>>> On 12/17/15 3:00 PM, "DOLLY, MARTIN C"  wrote:
>>>>>=20
>>>>> Tom
>>>>>=20
>>>>> That is the point and frustration, shouldn't we have an understanding=
=20
>>>>> of the regulatory requirements before blindly defining protocol?
>>>>>=20
>>>>> Martin C Dolly
>>>>> Lead Member of Technical Staff
>>>>> Core & Government/Regulatory Standards
>>>>> AT&T
>>>>> Cell: 609-903-3360
>>>>> Email: md3135@att.com
>>>>>=20
>>>>>> On Dec 17, 2015, at 2:49 PM, McGarry, Tom 
>>>>>> wrote:
>>>>>>=20
>>>>>> What's being designed are tools.  It is up to others, e.g.,=20
>>>>>> regulators, authorities, to decide how or whether to use those tools=
. =20
>>>>>> That's where the policy gets created.
>>>>>>=20
>>>>>> I know it has been controversial to suggest a tool (process) that=20
>>>>>> would  allow a consumer to acquire a telephone number directly, rath=
er=20
>>>>>> than thru  a service provider.  The most common identifier on the=20
>>>>>> Internet, domain  names, uses this model.  We're discussing=20
>>>>>> identifiers, telephone numbers,  on IP networks.  It would be=20
>>>>>> irresponsible and backward looking not to  account for this=20
>>>>>> possibility.
>>>>>>=20
>>>>>> The WG also includes the current process for number allocation, wher=
e=20
>>>>>> service providers acquire the numbers and they then in turn allocate=
=20
>>>>>> numbers to consumers.
>>>>>>=20
>>>>>> Entities that decide numbering policies can choose which tools they=
=20
>>>>>> do and  do not want to use.  That is where policies and regulations=
=20
>>>>>> are created.
>>>>>>=20
>>>>>> I know some people on this list refuse to believe this, not matter=20
>>>>>> how often it is said.  But those are the facts.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> On 12/17/15 1:27 PM, "Richard Hill"  wrote:
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>> -----Original Message-----
>>>>>>>> From: Adam Roach [mailto:adam@nostrum.com]
>>>>>>>> Sent: Thursday, December 17, 2015 19:12
>>>>>>>> To: Richard Hill; 'Brian Rosen'; 'Gorman, Pierce A [CTO]'
>>>>>>>> Cc: 'Richard Shockey'; 'Alissa Cooper'; 'Steve Donovan'; =20
>>>>>>>> modern@ietf.org
>>>>>>>> Subject: Re: [Modern] Problem statement draft as working group=20
>>>>>>>> document
>>>>>>>>=20
>>>>>>>>> On 12/17/15 12:07, Richard Hill wrote:
>>>>>>>>> Can you (or somebody else) explain to me how processes (which=20
>>>>>>>>> might
>>>>>>>> have regulatory implications) regarding assignment of E.164 number=
s=20
>>>>>>>> fall within the expertise of the IETF?
>>>>>>>>>=20
>>>>>>>>> Or have I misunderstood the scope of the work of this group?
>>>>>>>>=20
>>>>>>>> You have misunderstood the scope of the entire IETF. We design=20
>>>>>>>> network protocols. We are not part of any regulatory bodies. What=
=20
>>>>>>>> those bodies choose to do is entirely in their purview.
>>>>>>>=20
>>>>>>>=20
>>>>>>> Are you implying that the IETF can design a protocol without any=20
>>>>>>> reference whatsoever to whether it might violate existing laws and=
=20
>>>>>>> regulations?
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> /a
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> Modern mailing list
>>>>>>> Modern@ietf.org
>>>>>>>=20
>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org=
_mai
>>>>>>> lma
>>>>>>> n_
>>>>>>>=20
>>>>>>> listinfo_modern&d=3DCwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7=
HufveeID
>>>>>>> cLe
>>>>>>> xt
>>>>>>>=20
>>>>>>> Z1ooNcfp01IYIaVqsORjI&m=3DozfZfjKsWcLVXeIljVVsmxlsctjUYK9cpOGjPZWtB=
kw&s
>>>>>>> =3DLP
>>>>>>> GP
>>>>>>> t7cTP8zbe-1ZBrkEgho_MZXUC-S7QX5pGaOvL0U&e=3D
>>>>>>=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=3DCwIFAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7=
HufveeID
>>>>>> cLe=20
>>>>>> xtZ1ooNcfp01IYIaVqsORjI&m=3D6k6xBxpm7dn7KBeEKiMOttP4N0RYgrEx_jL-ZEio=
3tc&
>>>>>> s=3DR wfQDsbB7PHQvmP4WR0eqfXpetHM9q0n4Pr5CuIXEVU&e=3D
>>>>=20
>>>> _______________________________________________
>>>> Modern mailing list
>>>> Modern@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/modern
>>=20
>> _______________________________________________
>> Modern mailing list
>> Modern@ietf.org
>> https://www.ietf.org/mailman/listinfo/modern
>=20


From nobody Thu Dec 17 17:42: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 0337A1B31E4 for ; Thu, 17 Dec 2015 17:42:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 WQoKAHmeq5cc for ; Thu, 17 Dec 2015 17:42:50 -0800 (PST)
Received: from f5.bushwire.net (f5.bushwire.net [IPv6:2607:fc50:1000:5b00::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8991B31E6 for ; Thu, 17 Dec 2015 17:42:50 -0800 (PST)
Received: by f5.bushwire.net (Postfix, from userid 1001) id 2222AAC8D2; Thu, 17 Dec 2015 17:42:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2015; t=1450402969; bh=48DCmxwnJdaXWVjgiCSBlEc80Bs=; h=Comments:Received:Date:Message-ID:From:To:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=MVulav5EUMhOUfMR28vfPE7IMxNm7cThZlm0G7lEbg+RmYRzjFBG0U08GNcluJgD6 8mlieee4nVfDZHHHMQtgzR31aAFChY44aozUVNn3NWNWkfMbOggsFD8viiRBUMumcF oOKmdU7EWk739YHUSjY5klBjNbomcSVOrH/MvV10=MvV10=
Comments: QMDA 0.3
Received: (qmail 41762 invoked by uid 1001); 18 Dec 2015 01:42:49 -0000
Date: 18 Dec 2015 01:42:49 +0000
Message-ID: <20151218014249.41761.qmail@f5-external.bushwire.net>
From: "Mark Delany" 
To: modern@ietf.org
References:     <0F8F091A-7255-4781-81A3-48400BC670A1@att.com>  <1BD85DAA-9DC4-459F-91E1-A9ACD51F7CEC@att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <1BD85DAA-9DC4-459F-91E1-A9ACD51F7CEC@att.com>
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 18 Dec 2015 01:42:51 -0000

The Australian environment for one is likely to have growing interest
given the forced migration of practically all PSTN to VOIP as a
consequence of their National Broadband Network (NBN).

I don't know of the NZ experience first-hand, but given they are
making a similar transition many of the same issues will arise there.

Maybe not today, but given the life-cycle of the IETF processes, it's
entirely reasonable to think that WG product should keep these
regional trends in mind.


Mark.


From nobody Thu Dec 17 18:00: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 6ED161B320D for ; Thu, 17 Dec 2015 18:00:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfGmGJAz8oTg for ; Thu, 17 Dec 2015 18:00:52 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 4F4CA1B320C for ; Thu, 17 Dec 2015 18:00:52 -0800 (PST)
Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id tBI20Yfj030192; Thu, 17 Dec 2015 21:00:50 -0500
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 1ytsjgpytx-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);  Thu, 17 Dec 2015 21:00:50 -0500
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 tBI20njS030415; Thu, 17 Dec 2015 21:00:49 -0500
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 tBI20f7G029439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 17 Dec 2015 21:00:45 -0500
Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 18 Dec 2015 02:00:27 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.78]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0248.002; Thu, 17 Dec 2015 21:00:27 -0500
From: "DOLLY, MARTIN C" 
To: Mark Delany 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHROEiYt9tG2eQFXECnCpoLN3xbKp7OlCAAgADTIpCAAFmaAIAADhaAgAABNICAAAQrAIAAFuCA//+vSaiAAFmJgP//xGFAgABpgQD//7Ka5QAMIZ4A//+++IqAAFmKgP//sRz8
Date: Fri, 18 Dec 2015 02:00:27 +0000
Message-ID: <5A295305-2033-47F0-B98B-D82DF4A41458@att.com>
References:     <0F8F091A-7255-4781-81A3-48400BC670A1@att.com>  <1BD85DAA-9DC4-459F-91E1-A9ACD51F7CEC@att.com>, <20151218014249.41761.qmail@f5-external.bushwire.net>
In-Reply-To: <20151218014249.41761.qmail@f5-external.bushwire.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-12-18_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310007 definitions=main-1512180038
Archived-At: 
Cc: "modern@ietf.org" 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 18 Dec 2015 02:00:53 -0000

Please explain what exactly their interest is in?=20

Thanks

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards=20
AT&T
Cell: 609-903-3360
Email: md3135@att.com

> On Dec 17, 2015, at 8:42 PM, Mark Delany  wrote:
>=20
> The Australian environment for one is likely to have growing interest
> given the forced migration of practically all PSTN to VOIP as a
> consequence of their National Broadband Network (NBN).
>=20
> I don't know of the NZ experience first-hand, but given they are
> making a similar transition many of the same issues will arise there.
>=20
> Maybe not today, but given the life-cycle of the IETF processes, it's
> entirely reasonable to think that WG product should keep these
> regional trends in mind.
>=20
>=20
> Mark.
>=20
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern


From nobody Thu Dec 17 18:13:19 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E34F1B322B for ; Thu, 17 Dec 2015 18:13:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnSwbXYm1h7n for ; Thu, 17 Dec 2015 18:13:16 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C13891B3227 for ; Thu, 17 Dec 2015 18:13:16 -0800 (PST)
Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:54384 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1a9kXj-001WwP-Jh for modern@ietf.org; Thu, 17 Dec 2015 18:13:16 -0800
To: modern@ietf.org
References:     <0F8F091A-7255-4781-81A3-48400BC670A1@att.com>  <1BD85DAA-9DC4-459F-91E1-A9ACD51F7CEC@att.com>
From: Steve Donovan 
Message-ID: <56736BBA.9020300@usdonovans.com>
Date: Thu, 17 Dec 2015 20:13:14 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <1BD85DAA-9DC4-459F-91E1-A9ACD51F7CEC@att.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 18 Dec 2015 02:13:17 -0000

All,

We need to move this discussion off of the "should MODERN exist" thread 
to "should the existing problem statement draft become a working group 
draft."

MODERN is a working group in the IETF.  We need to work toward doing the 
work as outlined in the charter.

I would ask that everyone refrain from posting emails that repeat the 
discussions we had in the forming of the working group.  That ship has 
sailed.

So far the majority of the objections to promoting the problem statement 
draft have been in the vein of "MODERN shouldn't exist, thus the draft 
shouldn't exist".  This is not fruitful as MODERN does exist (see above).

There has been some discussions on the actual content of the draft, 
which is what we need and this is what needs to continue.

Note that promoting the draft does not mean that work is finished. 
Rather it means that the working group thinks it is a good starting 
point.  Those discussions on the actual content of the draft can and 
will continue if it becomes a working group draft.

So, I will repeat my original question -- Should the problem statement 
draft become a working group draft?

And I will add the following -- If your opinion is that it should not be 
a working group draft, please elaborate as to why you hold that 
opinion.  Or better yet, submit a draft that you think better addresses 
the architecture draft milestone in the charter.

Thanks,

Steve



From nobody Thu Dec 17 19:33: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 59E6D1B3292 for ; Thu, 17 Dec 2015 19:33:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQBYcmcf2dgc for ; Thu, 17 Dec 2015 19:33:51 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0727.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::727]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ACF61B3290 for ; Thu, 17 Dec 2015 19:33:51 -0800 (PST)
Received: from BN1AFFO11FD017.protection.gbl (10.58.52.33) by BN1AFFO11HUB045.protection.gbl (10.58.52.156) with Microsoft SMTP Server (TLS) id 15.1.346.13; Fri, 18 Dec 2015 03:33:31 +0000
Authentication-Results: spf=pass (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; usdonovans.com; dkim=none (message not signed) header.d=none;usdonovans.com; dmarc=bestguesspass action=none header.from=sprint.com;
Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.38 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.38; helo=plsapdm2.corp.sprint.com;
Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BN1AFFO11FD017.mail.protection.outlook.com (10.58.52.77) with Microsoft SMTP Server (TLS) id 15.1.355.15 via Frontend Transport; Fri, 18 Dec 2015 03:33:31 +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 tBI1RCaY029405;  Thu, 17 Dec 2015 21:33:31 -0600
Received: from prewe13m08.ad.sprint.com (prewe13m08.corp.sprint.com [144.226.128.27]) by plsapdm2.corp.sprint.com with ESMTP id 1ytsewws44-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 17 Dec 2015 21:33:30 -0600
Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M08.ad.sprint.com (2002:90e2:801b::90e2:801b) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 17 Dec 2015 22:33:29 -0500
Received: from PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed]) by PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed%24]) with mapi id 15.00.1076.000; Thu, 17 Dec 2015 21:33:29 -0600
From: "Gorman, Pierce A [CTO]" 
To: Steve Donovan 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHROEiYKCigIa6jakmAIZNM6lCGV57OlCAAgADTIpCAAGpeAIAADhaAgAABM4CAAAQrAIAAFuGAgAADGoCAAAW4gP//yWIfgABq64CAAA07AIAAEsqAgAAOOAD//7HWAg==
Date: Fri, 18 Dec 2015 03:33:29 +0000
Message-ID: <96016587-9D39-4290-BB03-FC5A225F0F6D@sprint.com>
References:     <0F8F091A-7255-4781-81A3-48400BC670A1@att.com>  <1BD85DAA-9DC4-459F-91E1-A9ACD51F7CEC@att.com>, <56736BBA.9020300@usdonovans.com>
In-Reply-To: <56736BBA.9020300@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD017; 1:tBzJWvow5+oiADsOrEiLmxHgrpECWbZfzMxqoYNmoCYgJsh37HgZFYwbhdAN7ARxeWteKVYfcEfRQRDCAw6Nkyzj8eY+7/YOB47kJV3Ft9Tb+Obr6sLA27atPD79Hkm6GZopva72u2AIgh3yOIKPw3VieaDZiffEhHCBCYfvyFtgWmftPYAMTReSd67nRnuX20R4eZgEvmCkuddFd79nzqidLfGV7TP0Tk+W7Gy3zuDBSnoB83BmO/XegFAY8oIHPD61DcJB1XPW4EQ6GL1wQ1pcQaVZVVR2qvZb5KDdsCFEr8U84GkLjS7LlDhajv4PAWixt9OZUmdz7JVtGIkHew==
X-Forefront-Antispam-Report: CIP:144.230.172.38; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(189002)(199003)(24454002)(377454003)(164054003)(586003)(5250100002)(1096002)(106116001)(97756001)(97736004)(6806005)(110136002)(19580405001)(33656002)(50986999)(54356999)(87936001)(76176999)(82746002)(50466002)(46406003)(5001960100002)(11100500001)(5008740100001)(189998001)(36756003)(83716003)(106466001)(15975445007)(81156007)(92566002)(1220700001)(23726003)(86362001)(2900100001)(102836003)(5003630100001)(15395725005)(2950100001)(19580395003)(93886004)(5003600100002)(47776003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB045; H:plsapdm2.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB045; 2:73n0pXO9WznBBlglA9QcJlzyAhyOfttbUeZm/4fKx3I0AFYVqSlZVIAEbm/nerctZwNGqH8QiqtSYtFWaA+jdCIv/v+Sgkeg6Oeets7cpO2tg5Ki1w+V5kPPVSltSffl4K6oUKgiKJCv34pLlRLBCQ==; 3:iEgjRwh0BQvPmINxHMUY9QNG2qXaY74U/qiUgWWMWyQhiJafBbX1S4xhNeJeUb9TAcPzuX1WFPP4Z8Y6aaPsc7/mtQRohAkkjWSj1iJUwSzP8htmQ/7RQrfnA9BiM++gbNt3VrwHVLFW0Vehs0NgcN8pOLG+yCm1/aSqsiQJrfa8KpeSIzIvrk78hc0A1/rh7hhg1u+pCefmbNTf5osdL2d3Ei12YcFx4jZL4jQPoMsuXQX8ZHAgvXVvNoJfNNQ5UPb4nZpg7qTIPEy1uB6bWQ==; 25:sAzVDrGR3XF0f3+9sOo5YJ+bG4J2GUSi5eL/0HqvGLbEu8Y3KK6sRAAv7XeRsLuHYtOu39ILb9cO443fLLf79nRW4trjtcCaCoKGCPfGyn4YV/+gZInQpPLSENsLJgrXxmj/sm7SnI6HMdBYurcpaRkN9Fm0TLguplJjXo5w3kO0xWJIeNAGZl/6B//Vda/IvglnB6lXqpl/tQNxzlRpoPKvb8ZbISS51i9fmca3kcAEHgr4b6PER1r3++SITuFFErzAquSyQzTSoaKHSHuKzw==
X-Exchange-Antispam-Report-Test: UriScan:; BCL:0; PCL:0; RULEID:(8251501002);  SRVR:BN1AFFO11HUB045; UriScan:(18430343700868);
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB045; 20:OCGLMcjdHC7JqWQsSQUZL0zbsvwoKIF2k9DSXtK0Y5HazPT2oRVliffWs9mk1s/5+M/qvf8LG8eJFfuupUOLxM5/iQIGd/IsxVivjsjTHVi5im3cZHQ5aJPeKAlVGmHg15FgALA9OcyZTNHtFvZ0D6PueRCIKbenN74MwWDSpg/PEeA/SeVlSV7aCI0i8xKNCoO9oXTOyieCeORvRzIKaPud21bpU5BESJ8dY1vRMEhVdEVqON/4aqm94Ncb8mHL; 4:ruwnNMpQr/XwGE1mfWGIQCXwOIo+GPNQdf15FgN0xFpCiG2KPAuWTVYKKrmKQDn1/aiNSHiSTuQFXn2yApdyj0klbtLQuAmxwUf8SXldSkw+PRmxyDN/nylED55YRGHLheX8HEHkUIyDoX+vaSVlap78x0pjk9jlHIbODY28P0MiyPysGg+17ppzs1xPVQHL+GZ0dg5WzJyErwOOX4nSFH/gXrbLToRqn6SEGvYF4EkJkw11o3fiLjHRJhtA3e4KfJZpjON8zUVeVgYwy5fqzdOaW81YNqxKqeFuMyd4FAuw9Vc4I8LE9r6cm7vg8YQ/VtUNSYL1zGqLhmAdN8hyBi4Wddois/ucYXGuMDZuHt2fVNdWg+ZNybwGOGebWx42ljZAcmN+FH+OVD0hs7llsSgt75mX8Q+FcpZgoeyh1AffFD4WM2I7lCktV1t32DDn
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001); SRVR:BN1AFFO11HUB045; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB045; 
X-Forefront-PRVS: 07943272E1
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1AFFO11HUB045; 23:8yoBOJZqCZCZONJGTQ4PTuBlei00zpc+AgYDif4?= =?us-ascii?Q?5hpYqSgiIzzrFHeEdtseR+fbeNTKdTdQ18d6CzzfUIVF/9SbUp6IYQeJr3Xq?= =?us-ascii?Q?sOaRAlud4EymsGBvRHl2jnVF2ku9r0eTFrUnuQ9kv+2kF5P464+GRPKK7H9o?= =?us-ascii?Q?olXxla9kbwG+HE8f8Bqj9imIxv0YztZitV41Dx9fkptC9loCSKelnCdRo3Tc?= =?us-ascii?Q?wn+N6OekdQIOfpoC4ekrkQOfqrtPOAkYSCbWFrJwu52V6pxzVmnxpWOsZK7r?= =?us-ascii?Q?z5iDfXJl8WhmzkTNvzCw5/Tx+PU9PwW4xDIIEowEXyeDiDM5buStfnfdHybc?= =?us-ascii?Q?PuoTwNbz7DhywGlJXxmDDLo+Vugwrrkwn0YN+GZF20i5k9Y3UP0qS/mTQ7C3?= =?us-ascii?Q?d1bbm/Y1xMhPNsLj50l7Kx00t20+tmIwBQ1Vvbkd0PNhQf2IwCG/rDh6u4Or?= =?us-ascii?Q?nD8yJGYRgBTOE9CHMx0NVrTe8A9cTXd3ZpKTR5vhIEMtu8EKlDo2Me6aFWBV?= =?us-ascii?Q?zH+57E5hRK3+ApCIYDq6SXaHVZDpKu92hJO2Hiye1Y4Tw0hzq3rlcybb3Zgw?= =?us-ascii?Q?sWW8XMe/W5BsMDJHmZjEMpCHz2Hlr+ePygnOAkRf4uxOTabHe4AU1a9Q6Nnm?= =?us-ascii?Q?0IxzDcXvw4f7f+ZMSLVgLTJaO/ux712lleS45axLhIglXStuMvQKZbR390v6?= =?us-ascii?Q?kvdJ0FMZipjtQeLWQm+S+Vvefk/fmWV9kKnLDTp7WilfTke7XkaKWRDKNldg?= =?us-ascii?Q?Ud9cH48MF1AgxFFOyW/HUStIkr24YtwkNGf4Ey6rdC69tpe0zaSyqlBIujA0?= =?us-ascii?Q?JG7QzF5hzSLCiqHarj2GcEdpXLJQdVEOhqapTgXpnkiKlPrJ8hZwwdpgSON+?= =?us-ascii?Q?p/8ruWoZ/LBmlAtAPs716Ohjl6p7/Fo9z32XfqlX3kCsfql/MwAnoi6rzCuO?= =?us-ascii?Q?OejefIEKaZA3QVg3DpJ79jZc8T2VCGcTI/pANPDAGjcm7C7CRPvj7FmekcMR?= =?us-ascii?Q?sEcvWvT7xoG7DLz4tJX03XUpK6rc9IgKqrHAh1wQwMlpvwLrwvi4R97NRdyJ?= =?us-ascii?Q?TiGSXO03FscrYX1fTSAaqzx0tHiQBWTY/7Uty/H9ZomZ0ZESxlkYNDFF8EVR?= =?us-ascii?Q?PQFJ/YFQGz19bgzzRkqCjUC0B8DET5geaKTO+8gfAlU2DJwMUhFxKtzJYBsM?= =?us-ascii?Q?fu+EjDJIbXOeISBZMpJEY3f8LDfEAw6ikbKWCqB+Vee40f4KDeQqkagAIAks?= =?us-ascii?Q?fyCPOy61Hl5xxkAM288lLkwNmouUCFzuhw5kwKQJk?=
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB045; 5:A+Nzl9IMmjTpYxh9cdWJu1dQy4JeDf6WSOPQnBPJmxq6AhiFJEWHdZIedqdZ1CR334RfQqcx332gd4jqIJZF4HkmXNpHN8taXSWYZU+BC0Pr3Po1qec6fPKVHErqHqrkQ/Yy6+irWv9Ax0fgYbG9jw==; 24:Bmbe23LfT8S55JL8gSFUX1SIbIO1GoP3UdkYq1Uc2gi6U/2ofg0/8AIUsH8Wh6TO4Fnm+y6XX9lT2a7iKttlYz9iTK5I6xfDRrxWLTybtgE=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: sprint.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2015 03:33:31.6588 (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: BN1AFFO11HUB045
Archived-At: 
Cc: "modern@ietf.org" 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 18 Dec 2015 03:33:56 -0000

In between reading the comments back and forth and starting and stopping co=
mments of my own, I've begun reading your problem statement.  It is difficu=
lt for me because I find myself loudly disagreeing (in my head) with nearly=
 every assertion and statement.  And I am unlikely to propose an alternativ=
e because of the fundamental problems many have raised and nearly as many h=
ave ignored.

Richard Shockey is right when he says that MODERN at least implies replacin=
g existing numbering administrative processes and systems.

Proposing a system (NOT a protocol) capable of replacing the world-wide set=
 of numbering authorities' administrative processes when you consider the q=
uantity of countries, and impacted regulatory authorities within the countr=
ies (e.g., 51 at least in the US at the federal and state levels) and/or un=
ion of countries or regions or states, let alone the impacted carriers with=
in each country, and add in the variations in uses of numbers such as toll =
free numbers, emergency services numbers, temporary location directory numb=
ers, and layer in variations in national and regional dialing plans, casual=
 calling, et cetera ad nauseum, what's been discussed so far as a problem s=
tatement is mostly not credible.

The folks that are dissatisfied with the chartering of MODERN, and in disag=
reement with the problem statement as it exists, are not against change.  M=
ost of us have important roles as agents of change within our respective do=
mains.

In developing database systems there are two basic methods.  Either a devel=
oper can envision a set of problems and devise a way to solve them and the =
users adapt to the vision of the developer, or the developers can learn and=
 develop to user specifications.

DNS is an example of the first methodology.   The most active contributors =
on this list are telling you MODERN needs to be the second.

I suspect it's possible the IETF may lack the expertise to understand the t=
elephone number problem space that the commercial carriers eat, live, and b=
reathe and have for decades.  MODERN can partner with the users (regulatory=
 authorities, carriers, alternative service providers, businesses, and cons=
umers) to learn their requirements, or it can persist down the path it's be=
en traveling so far.  The list of RFCs is very long and littered with DOA p=
rotocols and systems.  If you continue to ignore the considerable input you=
've been receiving, my opinion is you will most likely add to the litter.

Now, all that being said, I will resume my reading of the problem statement=
 and if I can convince myself that I can make a contribution that would be =
acceptable (which at the moment feels doubtful) then I will do so.

Sent from my iPad

> On Dec 17, 2015, at 8:13 PM, Steve Donovan  wro=
te:
>
> All,
>
> We need to move this discussion off of the "should MODERN exist" thread t=
o "should the existing problem statement draft become a working group draft=
."
>
> MODERN is a working group in the IETF.  We need to work toward doing the =
work as outlined in the charter.
>
> I would ask that everyone refrain from posting emails that repeat the dis=
cussions we had in the forming of the working group.  That ship has sailed.
>
> So far the majority of the objections to promoting the problem statement =
draft have been in the vein of "MODERN shouldn't exist, thus the draft shou=
ldn't exist".  This is not fruitful as MODERN does exist (see above).
>
> There has been some discussions on the actual content of the draft, which=
 is what we need and this is what needs to continue.
>
> Note that promoting the draft does not mean that work is finished. Rather=
 it means that the working group thinks it is a good starting point.  Those=
 discussions on the actual content of the draft can and will continue if it=
 becomes a working group draft.
>
> So, I will repeat my original question -- Should the problem statement dr=
aft become a working group draft?
>
> And I will add the following -- If your opinion is that it should not be =
a working group draft, please elaborate as to why you hold that opinion.  O=
r better yet, submit a draft that you think better addresses the architectu=
re draft milestone in the charter.
>
> Thanks,
>
> Steve
>
>
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern

________________________________
Switch to Sprint and save 50% on Verizon, AT&T or T-Mobile rates. Your savi=
ngs are guaranteed until 2018! Available on most plans. Limited time offer.=
 Exclusions and restrictions apply. See sprint.com/save50 for details.

________________________________

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


From nobody Thu Dec 17 22:51: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 08CBF1B33CA for ; Thu, 17 Dec 2015 22:51:41 -0800 (PST)
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, J_CHICKENPOX_41=0.6, 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 Sg5hrIyaSDBt for ; Thu, 17 Dec 2015 22:51:38 -0800 (PST)
Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C50221AD1FE for ; Thu, 17 Dec 2015 22:51:37 -0800 (PST)
Received: from smtp3.infomaniak.ch (smtp3.infomaniak.ch [84.16.68.91]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBI6pTYk029509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 18 Dec 2015 07:51:29 +0100
Received: from RHillNew (adsl-178-38-52-133.adslplus.ch [178.38.52.133]) (authenticated bits=0) by smtp3.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBI6pSL3015604; Fri, 18 Dec 2015 07:51:28 +0100
From: "Richard Hill" 
To: "'Alissa Cooper'" , "'DOLLY, MARTIN C'" 
References:    
In-Reply-To: 
Date: Fri, 18 Dec 2015 07:51:30 +0100
Message-ID: <000001d13960$86e14950$94a3dbf0$@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: AdE5H10mipnh3dXSSEajJDKgQbxaPgAQPBiA
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, "'McGarry, Tom'" 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 18 Dec 2015 06:51:41 -0000

Please see embedded comment below.

Thanks and best,
Richard

> -----Original Message-----
> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Alissa
> Cooper
> Sent: Friday, December 18, 2015 00:05
> To: DOLLY, MARTIN C
> Cc: modern@ietf.org; McGarry, Tom
> Subject: Re: [Modern] Problem statement draft as working group document
> 
> The IETF is an open organization with global participation. Any
> mechanisms defined in this or any other WG need to be flexible enough
> to accommodate requirements that exist or may be established in a
> variety of jurisdictions. Individual participants may concern
> themselves only with their home jurisdictions, but that does not
> eliminate the need to produce tools that can be used across
> jurisdictions.

In that case, would it make sense to seek to obtain input from regulators
outside the US? One way of doing that would be to transmit the current
working group document as a liaison to ITU-T Study Group 2, asking for
comments.

> 
> Alissa
> 
> > On Dec 17, 2015, at 4:49 PM, DOLLY, MARTIN C  wrote:
> >
> > That is the problem my friend. And note this is USA issue, so those
> that ask why IETF are involved are correct.
> >
> > I believe the IETF is good for parts but not the whole solution.
> >
> > Let us stop dancing around the naked emperor...
> >
> > -----Original Message-----
> > From: McGarry, Tom [mailto:Tom.McGarry@neustar.biz]
> > Sent: Thursday, December 17, 2015 3:21 PM
> > To: DOLLY, MARTIN C 
> > Cc: modern@ietf.org
> > Subject: Re: [Modern] Problem statement draft as working group
> > document
> >
> > No, that would get us involved with regulations and policies.  Our
> role is to understand the environment from a technology and process
> perspective, anticipate needs (e.g., perhaps including a more Internet-
> like model) and create solutions.  It's up to others to choose what
> they will and will not use.
> >
> > On 12/17/15 3:00 PM, "DOLLY, MARTIN C"  wrote:
> >
> >> Tom
> >>
> >> That is the point and frustration, shouldn't we have an
> understanding
> >> of the regulatory requirements before blindly defining protocol?
> >>
> >> Martin C Dolly
> >> Lead Member of Technical Staff
> >> Core & Government/Regulatory Standards AT&T
> >> Cell: 609-903-3360
> >> Email: md3135@att.com
> >>
> >>> On Dec 17, 2015, at 2:49 PM, McGarry, Tom 
> >>> wrote:
> >>>
> >>> What's being designed are tools.  It is up to others, e.g.,
> >>> regulators, authorities, to decide how or whether to use those
> tools.
> >>> That's where the policy gets created.
> >>>
> >>> I know it has been controversial to suggest a tool (process) that
> >>> would  allow a consumer to acquire a telephone number directly,
> >>> rather than thru  a service provider.  The most common identifier
> on
> >>> the Internet, domain  names, uses this model.  We're discussing
> >>> identifiers, telephone numbers,  on IP networks.  It would be
> >>> irresponsible and backward looking not to  account for this
> >>> possibility.
> >>>
> >>> The WG also includes the current process for number allocation,
> >>> where service providers acquire the numbers and they then in turn
> >>> allocate numbers to consumers.
> >>>
> >>> Entities that decide numbering policies can choose which tools they
> >>> do and  do not want to use.  That is where policies and regulations
> >>> are created.
> >>>
> >>> I know some people on this list refuse to believe this, not matter
> >>> how often it is said.  But those are the facts.
> >>>
> >>>
> >>>
> >>>
> >>>> On 12/17/15 1:27 PM, "Richard Hill"  wrote:
> >>>>
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Adam Roach [mailto:adam@nostrum.com]
> >>>>> Sent: Thursday, December 17, 2015 19:12
> >>>>> To: Richard Hill; 'Brian Rosen'; 'Gorman, Pierce A [CTO]'
> >>>>> Cc: 'Richard Shockey'; 'Alissa Cooper'; 'Steve Donovan';
> >>>>> modern@ietf.org
> >>>>> Subject: Re: [Modern] Problem statement draft as working group
> >>>>> document
> >>>>>
> >>>>>> On 12/17/15 12:07, Richard Hill wrote:
> >>>>>> Can you (or somebody else) explain to me how processes (which
> >>>>>> might
> >>>>> have regulatory implications) regarding assignment of E.164
> >>>>> numbers fall within the expertise of the IETF?
> >>>>>>
> >>>>>> Or have I misunderstood the scope of the work of this group?
> >>>>>
> >>>>> You have misunderstood the scope of the entire IETF. We design
> >>>>> network protocols. We are not part of any regulatory bodies. What
> >>>>> those bodies choose to do is entirely in their purview.
> >>>>
> >>>>
> >>>> Are you implying that the IETF can design a protocol without any
> >>>> reference whatsoever to whether it might violate existing laws and
> >>>> regulations?
> >>>>
> >>>>>
> >>>>> /a
> >>>>
> >>>> _______________________________________________
> >>>> Modern mailing list
> >>>> Modern@ietf.org
> >>>>
> >>>> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_m
> >>>> ai
> >>>> lma
> >>>> n_
> >>>>
> >>>>
> listinfo_modern&d=CwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7Hufvee
> >>>> ID
> >>>> cLe
> >>>> xt
> >>>>
> >>>>
> Z1ooNcfp01IYIaVqsORjI&m=ozfZfjKsWcLVXeIljVVsmxlsctjUYK9cpOGjPZWtBkw
> >>>> &s
> >>>> =LP
> >>>> GP
> >>>> t7cTP8zbe-1ZBrkEgho_MZXUC-S7QX5pGaOvL0U&e=
> >>>
> >>> _______________________________________________
> >>> Modern mailing list
> >>> Modern@ietf.org
> >>>
> >>> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_ma
> >>> il
> >>> man
> >>>
> _listinfo_modern&d=CwIFAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7Hufvee
> >>> ID
> >>> cLe
> >>> xtZ1ooNcfp01IYIaVqsORjI&m=6k6xBxpm7dn7KBeEKiMOttP4N0RYgrEx_jL-
> ZEio3t
> >>> c& s=R wfQDsbB7PHQvmP4WR0eqfXpetHM9q0n4Pr5CuIXEVU&e=
> >
> > _______________________________________________
> > Modern mailing list
> > Modern@ietf.org
> > https://www.ietf.org/mailman/listinfo/modern
> 
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern


From nobody Thu Dec 17 22:53:19 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D271B33D5 for ; Thu, 17 Dec 2015 22:53:17 -0800 (PST)
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, J_CHICKENPOX_21=0.6, 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 8e1UXQICmONv for ; Thu, 17 Dec 2015 22:53:15 -0800 (PST)
Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBEBD1B33BB for ; Thu, 17 Dec 2015 22:53:14 -0800 (PST)
Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBI6r5fQ031264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 18 Dec 2015 07:53:05 +0100
Received: from RHillNew (adsl-178-38-52-133.adslplus.ch [178.38.52.133]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBI6r45u032485; Fri, 18 Dec 2015 07:53:04 +0100
From: "Richard Hill" 
To: "'Brian Rosen'" , "'DOLLY, MARTIN C'" 
References:     <0F8F091A-7255-4781-81A3-48400BC670A1@att.com> 
In-Reply-To: 
Date: Fri, 18 Dec 2015 07:53:05 +0100
Message-ID: <000301d13960$c0304e90$4090ebb0$@ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdE5KS4UQcN4WiWuSKaZkkqCVHfinwAN17Dw
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: 'Alissa Cooper' , modern@ietf.org, 'Tom McGarry' 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 18 Dec 2015 06:53:17 -0000

Please see below.

Thanks and best,
Richard

> -----Original Message-----
> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Brian Rosen
> Sent: Friday, December 18, 2015 01:15
> To: DOLLY, MARTIN C
> Cc: modern@ietf.org; Alissa Cooper; Tom McGarry
> Subject: Re: [Modern] Problem statement draft as working group =
document
>=20
> I=E2=80=99ve talked to a couple of regulators beyond the U.S. ones.  =
Some EU,
> some smaller nations.  As you know, a number of regulators send folks
> to IETF meetings.  They are VERY interested. =20

Interest would probably be broadened and deepened if the group's charter =
and the draft working group document were submitted as a liaison =
statement to ITU-T Study Group 2.


> I wouldn=E2=80=99t say anyone is
> committed, just interested.
>=20
> Brian
>=20
> > On Dec 17, 2015, at 6:27 PM, DOLLY, MARTIN C  wrote:
> >
> > Alissa
> >
> > Please explain which country outside the USA this is being driven =
by?
> >
> > I asked all my 3GPP colleagues, and the answer is none.
> >
> > Look at the carrier participation on the list
> >
> > If it looks like a duck, maybe it is a duck
> >
> > Martin C Dolly
> > Lead Member of Technical Staff
> > Core & Government/Regulatory Standards AT&T
> > Cell: 609-903-3360
> > Email: md3135@att.com
> >
> >> On Dec 17, 2015, at 6:05 PM, Alissa Cooper 
> wrote:
> >>
> >> The IETF is an open organization with global participation. Any
> mechanisms defined in this or any other WG need to be flexible enough
> to accommodate requirements that exist or may be established in a
> variety of jurisdictions. Individual participants may concern
> themselves only with their home jurisdictions, but that does not
> eliminate the need to produce tools that can be used across
> jurisdictions.
> >>
> >> Alissa
> >>
> >>> On Dec 17, 2015, at 4:49 PM, DOLLY, MARTIN C 
> wrote:
> >>>
> >>> That is the problem my friend. And note this is USA issue, so =
those
> that ask why IETF are involved are correct.
> >>>
> >>> I believe the IETF is good for parts but not the whole solution.
> >>>
> >>> Let us stop dancing around the naked emperor...
> >>>
> >>> -----Original Message-----
> >>> From: McGarry, Tom [mailto:Tom.McGarry@neustar.biz]
> >>> Sent: Thursday, December 17, 2015 3:21 PM
> >>> To: DOLLY, MARTIN C 
> >>> Cc: modern@ietf.org
> >>> Subject: Re: [Modern] Problem statement draft as working group
> >>> document
> >>>
> >>> No, that would get us involved with regulations and policies.  Our
> role is to understand the environment from a technology and process
> perspective, anticipate needs (e.g., perhaps including a more =
Internet-
> like model) and create solutions.  It's up to others to choose what
> they will and will not use.
> >>>
> >>>> On 12/17/15 3:00 PM, "DOLLY, MARTIN C"  wrote:
> >>>>
> >>>> Tom
> >>>>
> >>>> That is the point and frustration, shouldn't we have an
> >>>> understanding of the regulatory requirements before blindly
> defining protocol?
> >>>>
> >>>> Martin C Dolly
> >>>> Lead Member of Technical Staff
> >>>> Core & Government/Regulatory Standards AT&T
> >>>> Cell: 609-903-3360
> >>>> Email: md3135@att.com
> >>>>
> >>>>> On Dec 17, 2015, at 2:49 PM, McGarry, Tom
> >>>>> 
> >>>>> wrote:
> >>>>>
> >>>>> What's being designed are tools.  It is up to others, e.g.,
> >>>>> regulators, authorities, to decide how or whether to use those
> tools.
> >>>>> That's where the policy gets created.
> >>>>>
> >>>>> I know it has been controversial to suggest a tool (process) =
that
> >>>>> would  allow a consumer to acquire a telephone number directly,
> >>>>> rather than thru  a service provider.  The most common =
identifier
> >>>>> on the Internet, domain  names, uses this model.  We're
> discussing
> >>>>> identifiers, telephone numbers,  on IP networks.  It would be
> >>>>> irresponsible and backward looking not to  account for this
> >>>>> possibility.
> >>>>>
> >>>>> The WG also includes the current process for number allocation,
> >>>>> where service providers acquire the numbers and they then in =
turn
> >>>>> allocate numbers to consumers.
> >>>>>
> >>>>> Entities that decide numbering policies can choose which tools
> >>>>> they do and  do not want to use.  That is where policies and
> >>>>> regulations are created.
> >>>>>
> >>>>> I know some people on this list refuse to believe this, not
> matter
> >>>>> how often it is said.  But those are the facts.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On 12/17/15 1:27 PM, "Richard Hill"  wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Adam Roach [mailto:adam@nostrum.com]
> >>>>>>> Sent: Thursday, December 17, 2015 19:12
> >>>>>>> To: Richard Hill; 'Brian Rosen'; 'Gorman, Pierce A [CTO]'
> >>>>>>> Cc: 'Richard Shockey'; 'Alissa Cooper'; 'Steve Donovan';
> >>>>>>> modern@ietf.org
> >>>>>>> Subject: Re: [Modern] Problem statement draft as working group
> >>>>>>> document
> >>>>>>>
> >>>>>>>> On 12/17/15 12:07, Richard Hill wrote:
> >>>>>>>> Can you (or somebody else) explain to me how processes (which
> >>>>>>>> might
> >>>>>>> have regulatory implications) regarding assignment of E.164
> >>>>>>> numbers fall within the expertise of the IETF?
> >>>>>>>>
> >>>>>>>> Or have I misunderstood the scope of the work of this group?
> >>>>>>>
> >>>>>>> You have misunderstood the scope of the entire IETF. We design
> >>>>>>> network protocols. We are not part of any regulatory bodies.
> >>>>>>> What those bodies choose to do is entirely in their purview.
> >>>>>>
> >>>>>>
> >>>>>> Are you implying that the IETF can design a protocol without =
any
> >>>>>> reference whatsoever to whether it might violate existing laws
> >>>>>> and regulations?
> >>>>>>
> >>>>>>>
> >>>>>>> /a
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Modern mailing list
> >>>>>> Modern@ietf.org
> >>>>>>
> >>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> 3A__www.ietf.org
> >>>>>> _mai
> >>>>>> lma
> >>>>>> n_
> >>>>>>
> >>>>>>
> =
listinfo_modern&d=3DCwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufv
> >>>>>> eeID
> >>>>>> cLe
> >>>>>> xt
> >>>>>>
> >>>>>>
> Z1ooNcfp01IYIaVqsORjI&m=3DozfZfjKsWcLVXeIljVVsmxlsctjUYK9cpOGjPZWtB
> >>>>>> kw&s
> >>>>>> =3DLP
> >>>>>> GP
> >>>>>> t7cTP8zbe-1ZBrkEgho_MZXUC-S7QX5pGaOvL0U&e=3D
> >>>>>
> >>>>> _______________________________________________
> >>>>> Modern mailing list
> >>>>> Modern@ietf.org
> >>>>>
> >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> 3A__www.ietf.org_
> >>>>> mail
> >>>>> man
> >>>>>
> =
_listinfo_modern&d=3DCwIFAg&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufv
> >>>>> eeID
> >>>>> cLe
> >>>>> xtZ1ooNcfp01IYIaVqsORjI&m=3D6k6xBxpm7dn7KBeEKiMOttP4N0RYgrEx_jL-
> ZEio
> >>>>> 3tc& s=3DR wfQDsbB7PHQvmP4WR0eqfXpetHM9q0n4Pr5CuIXEVU&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
>=20
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern



From nobody Fri Dec 18 02:46: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 7FB3F1B359C for ; Fri, 18 Dec 2015 02:46:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level: 
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 nEn535rOnJuj for ; Fri, 18 Dec 2015 02:46:14 -0800 (PST)
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 810E31A8A12 for ; Fri, 18 Dec 2015 02:46:13 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 2B2C21D964F2C; Fri, 18 Dec 2015 10:45:58 +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 tBIAjwbM022918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Dec 2015 11:45:59 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.213]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 18 Dec 2015 11:45:58 +0100
From: "DRAGE, Keith (Keith)" 
To: Mark Delany , "modern@ietf.org" 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHROEiYA2pZs961mEyzUnBHV0eSQZ7OlCAAgADTIpCAAFmaAIAADhaAgAABNICAAAQrAIAAFuCA//+vSaiAAFmJgP//xGFAgAAE7ACAAAZsgIAADToAgAASyoCAAAW4gIAAp9fg
Date: Fri, 18 Dec 2015 10:45:58 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8BADE25DCC@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References:     <0F8F091A-7255-4781-81A3-48400BC670A1@att.com>  <1BD85DAA-9DC4-459F-91E1-A9ACD51F7CEC@att.com> <20151218014249.41761.qmail@f5-external.bushwire.net>
In-Reply-To: <20151218014249.41761.qmail@f5-external.bushwire.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.41]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 18 Dec 2015 10:46:16 -0000

I am not aware that VOIP transition is requires the MODERN work as a precon=
dition.

It is just a tool that some people think might be used (and that is potenti=
ally independent of VOIP usage).

Regards

Keith

-----Original Message-----
From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Mark Delany
Sent: 18 December 2015 01:43
To: modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

The Australian environment for one is likely to have growing interest given=
 the forced migration of practically all PSTN to VOIP as a consequence of t=
heir National Broadband Network (NBN).

I don't know of the NZ experience first-hand, but given they are making a s=
imilar transition many of the same issues will arise there.

Maybe not today, but given the life-cycle of the IETF processes, it's entir=
ely reasonable to think that WG product should keep these regional trends i=
n mind.


Mark.

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


From nobody Fri Dec 18 04:50:13 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E142C1B2BBC for ; Fri, 18 Dec 2015 04:50:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onlcZ6Lf-tDR for ; Fri, 18 Dec 2015 04:50:07 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0110.outbound.protection.outlook.com [207.46.100.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43DDC1B2F51 for ; Fri, 18 Dec 2015 04:50:07 -0800 (PST)
Received: from BN1BFFO11FD005.protection.gbl (10.58.144.31) by BN1BFFO11HUB022.protection.gbl (10.58.144.169) with Microsoft SMTP Server (TLS) id 15.1.355.15; Fri, 18 Dec 2015 12:50:05 +0000
Authentication-Results: spf=pass (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; cooperw.in; dkim=none (message not signed) header.d=none;cooperw.in; dmarc=bestguesspass action=none header.from=sprint.com;
Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.38 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.38; helo=plsapdm2.corp.sprint.com;
Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BN1BFFO11FD005.mail.protection.outlook.com (10.58.144.68) with Microsoft SMTP Server (TLS) id 15.1.355.15 via Frontend Transport; Fri, 18 Dec 2015 12:50:04 +0000
Received: from pps.filterd (plsapdm2.corp.sprint.com [127.0.0.1]) by plsapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id tBI8NvnH029405;  Fri, 18 Dec 2015 06:50:04 -0600
Received: from plswe13m08.ad.sprint.com (plswe13m08.corp.sprint.com [144.229.214.27]) by plsapdm2.corp.sprint.com with ESMTP id 1ytsex02ky-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 18 Dec 2015 06:50:04 -0600
Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 18 Dec 2015 06:50:03 -0600
Received: from PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed]) by PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed%24]) with mapi id 15.00.1076.000; Fri, 18 Dec 2015 06:50:03 -0600
From: "Gorman, Pierce A [CTO]" 
To: Adam Roach 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHROEiYKCigIa6jakmAIZNM6lCGV57OlCAAgADTIpCAAGpeAIAACymAgAAHQYCAANCdQg==
Date: Fri, 18 Dec 2015 12:50:02 +0000
Message-ID: 
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com> <056701d136a3$e1c49120$a54db360$@ch> <566F1A34.9020402@nostrum.com> <6C827E0C-682C-4484-8F21-20A446746858@shockey.us> <0F2A509D-5DEA-4416-BEEF-3D814C4D02E3@cooperw.in>   <62D8976B-8132-4C80-9656-6A3BD6853EE8@brianrosen.net> <7082DBCA-ABC9-4DFD-90EC-32C5EEEE078C@shockey.us>, <5672FD9B.6060008@nostrum.com>
In-Reply-To: <5672FD9B.6060008@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD005; 1:wwxnxmhAMyD+7kLhZl/+pJovBIIsGfYQOYC9Is7K076IhUiMHG3h9CsNNBTmp303RK96TC/57DJU5nFn2XQvYCH4SnfjcvCLBQ+MNbeb/odTo01gd6Suw97F8TT40sLPVZDBzMQzz2sAn7iuivusXagWWlfsUabFe4UM8JLjN3C+eCVSSnC+BO4G1QoDaMxT9wrZk6uWe1rSZLXpr48mF5icG/I2xRcLM8fF7fUFEzu8TqBwD1vwzSEkXWiEfCBUJ/shMjkdL9//8Y6hjSBfntXu/lg8KkgT806HLIz2ldGoM3cw3EIr14LniLjtDcOjR8vCrMchfHGhXIFeUQ1IZwEJSZ58qsWGMIVbUgHlG7XqG7ymmKyoRdyG+U90Phu3
X-Forefront-Antispam-Report: CIP:144.230.172.38; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(377454003)(479174004)(199003)(189002)(24454002)(93886004)(106466001)(47776003)(33656002)(5003600100002)(106116001)(5003630100001)(5001960100002)(19580405001)(81156007)(97736004)(19580395003)(189998001)(110136002)(92566002)(82746002)(5250100002)(97756001)(46406003)(11100500001)(50466002)(36756003)(1096002)(15975445007)(6806005)(2900100001)(5008740100001)(23726003)(76176999)(102836003)(1220700001)(87936001)(86362001)(83716003)(586003)(15395725005)(50986999)(54356999)(2950100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB022; H:plsapdm2.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB022; 2:7/JzaPyxqWewoqDbB32aoGKmACq2Q4JrL1+Tzn3k8/+cjGk6Qk4gyQdrqmmpRXdPgUhSChxlocKpMnemmOYZT26ZEDff7YI3CCJ/aQKUxf09RcP3kGAxqI0by7rPDgN6n2B1VwgNd3pzX8wGjKnn2g==; 3:LFVrus+df4LqiJPylHKxPKMMyl+Qk3wVISG2uMCwg01S9vTJNGc8MdAvUa+SCqGUSDQsKfh9xqVp31Ylq3iftJFk5ZN+kvh2Yg7uja38JYcwqoIQOD9jbx16DBYU2BWu/yz/VhY7OjFO9lK5ZQn4ew1Vya4agqZyY87aTL8Cs6rZiV58eofhmQOgKTCbFo7EW3rGdkH2dTKebmG1F+/wAa/d1LpGxnJeQH0HzoWfHQzLM0qQX2r1uuTSQku/J8hO1s3MV7lJKQwTTwzSUPI6oQ==; 25:oMDMRwlCNGOxayL1G8CHd8owbPvNxPqa2VoX9hp5efY0X9beW5CzLyKR7SsmlXCsT/AmiCURn1CbVeY1H/SwWBT240F0GRcoUWr9pWgxuya9ZwBo58ODx4vj7fn56mkz967pKz4wwfwoFEIUGjETTsa+4ZoZTHrD7l2ZSL8cnJ+7t9cwEqYNVkoQQuDGcoc5TrZEpOrnpcz2AJNTQ1iSgmjfChuPL55zQLF5rB+HQfH1uXLza7f1xFNgXKuEs1nLmFgingThUjtuNa3zLNaxPw==
X-Exchange-Antispam-Report-Test: UriScan:; BCL:0; PCL:0; RULEID:(8251501002);  SRVR:BN1BFFO11HUB022; UriScan:(18430343700868);
X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB022; 20:Wpi3GCARaRMhMehKhx7X1eu4fM1Ugw4zMuEgUWVgx8haAAuuNvwN3G8f0HUm3k8wNjU0gznLu4SEywlHOYnAdcR9lBnB4bfZTSfIbjJBteMb//1Q5PcbXHrHJRY+oGbTOD6EO16IGCLvCEOFISNT4TWGjdsi23ci49fM5F9f1oU0gQa7gBVENknE4SHOTYKG73RcU0/bRUr17RPzTzNunfYgsqrsFRdsONpLrDaFjAdi5x/xoflIq6Q21EjkP+Aq; 4:BVpKUVffftBLW5Et+UqzV2C/96PZelhGUZ4R2g4c6+qdqXFS8SlIzIoko7ZJ7qCKhAIt/+oxF75FWJFQWvNk6Dl5qnOiTc5nb0/L6e4lwsDsTxNNfflq7PBEmgmK1KAI+5dDXxa5j7NYjtAnJdOpU9bvN56GPzczeiXK6vgVfIEkgl/OQNkPlMFGJijHAW0xZgOe0Y5d4l3/K32QM/WtohPcrRy+cdPDkxPFaQn+YVVv3loYyLy/mU6WODDrwgd6eY5OjWJGgaO9TEVw73PmylrSdVL7Xcznfs1wrDnGX8dh41scFV2ZTtFQmjhbBb+VOZiJGSkrTBSFr6t2ywDihv7AFh2i3cV/D8cPTdJBNNlQBhR+TsQ4OSaa96juR6u1yDCT9AlO1jeuWm2xd+IIg83tsbznoLHXYxOeDM1ek5/wUajjroqW6ymCEUQdpS99
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046); SRVR:BN1BFFO11HUB022; BCL:0; PCL:0; RULEID:; SRVR:BN1BFFO11HUB022; 
X-Forefront-PRVS: 07943272E1
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1BFFO11HUB022; 23:d06pkHbClY9dc5c+jb6JE1KspLsDjyUnhgOtuJ0?= =?us-ascii?Q?IW9Scwaw27x0Zp3zh79TkXrJ2zfkH0HMQRLdLO8U63PyqHccppVmzMa7a8z3?= =?us-ascii?Q?g94Rtzs9ZfNinddzDg0zi0mGGMMPkNCE6kq/dfLRGM3aTj2O9ZiQb5SH+D0J?= =?us-ascii?Q?Ds9sYKtFNhIi1DI9cnx/LfJCjtZuZ5weKuJ/ZpzfHXG3pdhi5xmCGFz54fKB?= =?us-ascii?Q?RQvCmWNFFFs3Ag8FlE3/OjYBRtu3tazxqV5pVcKyW6Lkmd99hadehvZlpOwR?= =?us-ascii?Q?DOg7qCU+ceaYpt0K3ghjpV5K7hg7V6UzBg78dwPoCsqYErdJUWs/NHAfqKX1?= =?us-ascii?Q?uxDnlXTWfpEXEsvCnX820U5MIXISpWMNERt2ns5MwBF+7ohSZrfDSn6gb3zY?= =?us-ascii?Q?c/yZcSuPJJEnC1uBJov9/vXCBTojjJi9j9we+HXsrauQGxaaRnW5mV9GCI28?= =?us-ascii?Q?6DMW6U+vj0WXFCLVw3STo4vINph9GQvZ0VUAnIuFo7zGBGrJgCMNaebT4aVQ?= =?us-ascii?Q?4jlJX993yAr7Bri9H4k4MTQ2pzJzHihGWSwDpR1+1ctzd68SEE7D5p8okDUk?= =?us-ascii?Q?+nmntZBWsyf2BML1moLqenHeNuFPvayWk3vEmL/wHEac3enxPGK1EBm307g8?= =?us-ascii?Q?I7x+wb/V59h+YM1Fh5Ygz6eE4rAfzDGD7s5ipTPrvHI676g2KLH1qredEcOZ?= =?us-ascii?Q?zJi6qxpCrEVJhbeBgGXWgqHn00k6kwKqZ4tT7glZCi63jV9Aj2+49c2jEJJF?= =?us-ascii?Q?Ibq0XLwsa7Jf5HhcMaQAZ9Lz3aOwLuGUwE1XG1tLkKj8sUo1Icnhedo+4aBY?= =?us-ascii?Q?wDfOGDMMY2UBeuZzH5tuHVzl9YSg55FKA8VIaS2g7Kh7e2GjxKItgbwAUBTc?= =?us-ascii?Q?++Xn2yQ/Fbs8DQg2VBCMaTZTOeBMBjoQV9aQA4xF+QzIzqHua7bP+K6QczfT?= =?us-ascii?Q?IcKwcnVAjHXlKwTX2JSe1pr2fEf4SDcGSPbDIkyGyP+Leom34sj/w+w+Zkkw?= =?us-ascii?Q?g1Hakr1tFGhdeoNpxKHpYiM/UjTCO3JNFHQKmDUf7gnOyAo//I1xvdjPKP8q?= =?us-ascii?Q?g/Jk81QUGwEliAEDbiIeZDTycJ4XC/9nFN6YZJmJreqOzrgKpvwlIbqii4ap?= =?us-ascii?Q?nO8W63UxtftKi4E8SqJ76oE5lZ7sjoHsyIggMFGxoVslsPFzoY1A5WowTjt4?= =?us-ascii?Q?2fES3jMKziytZWdiQHm8aQYw7hw1sqHOr2ix4zMgTjZ14Z6xDyjq5cTgSrnQ?= =?us-ascii?Q?jMvzZQYuNVcG3zUAkQBJmbR5a2surV0u7hxKfRItU?=
X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB022; 5:j/jiVWRiXsIDH+KNtFtGi2PXAcD2fmDETCzDdifR5mugwIiHi/A5Nh5Dz6kS7NU3fTgb+lKAw7hEFZkmzcYoUqydZMQfJkupJSX+hQUTZJje2qZFl2hDFbi6dPHuOgJ0gmK0oiIM/TjOGD5lGMfVlA==; 24:9gaaWXE5VTHuH1xRb8KVC0fWw6FZ4rAsPwvW5fZLlc7DXSdm3vpKdQcGwr9/DfBQOmDZDAWsC0nr9X1a6EEj0n9X1j4s68xDFWS87x+nuu4=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: sprint.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2015 12:50:04.7324 (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: BN1BFFO11HUB022
Archived-At: 
Cc: Steve Donovan , Alissa Cooper , "modern@ietf.org" , Richard Shockey , Brian Rosen , Richard Hill 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 18 Dec 2015 12:50:12 -0000

Beyond persevering regardless of input and feedback, were there other lesso=
ns learned in CODEC that could be applied in this working group?

Rich Hill's suggestion that learning requirements through an ITU study grou=
p could be beneficial seems logical.

I'm not suggesting this as a stall tactic.  I'm suggesting that MODERN is t=
aking on a global challenge and could benefit from Rich's suggestion.  Are =
there good reasons to ignore it?

Sent from my iPad

> On Dec 17, 2015, at 12:23 PM, Adam Roach  wrote:
>
>> On 12/17/15 11:57, Richard Shockey wrote:
>> RS> Which some of us dispute. I really really believe that E.164 numberi=
ng allocation is not within the Expertise of the IETF.
>
> An incredibly congruent objection was raised by several parties in the ch=
artering of CODEC. The result of proceeding anyway was objectively and subj=
ectively the best audio codec ever produced.
>
> /a
>
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern

________________________________
Switch to Sprint and save 50% on Verizon, AT&T or T-Mobile rates. Your savi=
ngs are guaranteed until 2018! Available on most plans. Limited time offer.=
 Exclusions and restrictions apply. See sprint.com/save50 for details.

________________________________

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


From nobody Fri Dec 18 04:53: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 C82761B35F9 for ; Fri, 18 Dec 2015 04:53:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QY0z9pVaeMKm for ; Fri, 18 Dec 2015 04:53:25 -0800 (PST)
Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27FFA1B35EF for ; Fri, 18 Dec 2015 04:53:25 -0800 (PST)
Received: from smtp3.infomaniak.ch (smtp3.infomaniak.ch [84.16.68.91]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBICrB2I009582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 18 Dec 2015 13:53:12 +0100
Received: from RHillNew (adsl-178-38-52-133.adslplus.ch [178.38.52.133]) (authenticated bits=0) by smtp3.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBICr5re021859; Fri, 18 Dec 2015 13:53:06 +0100
From: "Richard Hill" 
To: "'Gorman, Pierce A [CTO]'" , "'Adam Roach'" 
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com> <056701d136a3$e1c49120$a54db360$@ch> <566F1A34.9020402@nostrum.com> <6C827E0C-682C-4484-8F21-20A446746858@shockey.us> <0F2A509D-5DEA-4416-BEEF-3D814C4D02E3@cooperw.in>   <62D8976B-8132-4C80-9656-6A3BD6853EE8@brianrosen.net> <7082DBCA-ABC9-4DFD-90EC-32C5EEEE078C@shockey.us>, <5672FD9B.6060008@nostrum.com> 
In-Reply-To: 
Date: Fri, 18 Dec 2015 13:53:07 +0100
Message-ID: <00ad01d13993$0e436a90$2aca3fb0$@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: AQHROEiYKCigIa6jakmAIZNM6lCGV57OlCAAgADTIpCAAGpeAIAACymAgAAHQYCAANCdQoAAAH5A
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: 'Steve Donovan' , 'Brian Rosen' , modern@ietf.org, 'Alissa Cooper' , 'Richard Shockey' 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 18 Dec 2015 12:53:28 -0000

To be clear, I'm not suggesting that this group pause its work or wait for
inputs from ITU-T. I'm suggesting that it inform ITU-T of where it stands
and continue its work. If ITU-T replies, then the group could take that
input into account in due course.

Best,
Richard

> -----Original Message-----
> From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com]
> Sent: Friday, December 18, 2015 13:50
> To: Adam Roach
> Cc: Richard Shockey; Brian Rosen; Steve Donovan; Richard Hill;
> modern@ietf.org; Alissa Cooper
> Subject: Re: [Modern] Problem statement draft as working group document
> 
> Beyond persevering regardless of input and feedback, were there other
> lessons learned in CODEC that could be applied in this working group?
> 
> Rich Hill's suggestion that learning requirements through an ITU study
> group could be beneficial seems logical.
> 
> I'm not suggesting this as a stall tactic.  I'm suggesting that MODERN
> is taking on a global challenge and could benefit from Rich's
> suggestion.  Are there good reasons to ignore it?
> 
> Sent from my iPad
> 
> > On Dec 17, 2015, at 12:23 PM, Adam Roach  wrote:
> >
> >> On 12/17/15 11:57, Richard Shockey wrote:
> >> RS> Which some of us dispute. I really really believe that E.164
> numbering allocation is not within the Expertise of the IETF.
> >
> > An incredibly congruent objection was raised by several parties in
> the chartering of CODEC. The result of proceeding anyway was
> objectively and subjectively the best audio codec ever produced.
> >
> > /a
> >
> > _______________________________________________
> > Modern mailing list
> > Modern@ietf.org
> > https://www.ietf.org/mailman/listinfo/modern
> 
> ________________________________
> Switch to Sprint and save 50% on Verizon, AT&T or T-Mobile rates. Your
> savings are guaranteed until 2018! Available on most plans. Limited
> time offer. Exclusions and restrictions apply. See
> sprint.com/save50 for details.
> 
> ________________________________
> 
> This e-mail may contain Sprint proprietary information intended for the
> sole use of the recipient(s). Any use by others is prohibited. If you
> are not the intended recipient, please contact the sender and delete
> all copies of the message.



From nobody Fri Dec 18 05:58: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 792F81B364A for ; Fri, 18 Dec 2015 05:58:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fooPvacJVMu2 for ; Fri, 18 Dec 2015 05:58:55 -0800 (PST)
Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 838FD1B3649 for ; Fri, 18 Dec 2015 05:58:55 -0800 (PST)
Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id tBIDwhq9002771; Fri, 18 Dec 2015 08:58:44 -0500
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049458.ppops.net-00191d01. with ESMTP id 1yu0w3ekqp-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);  Fri, 18 Dec 2015 08:58:43 -0500
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 tBIDwWax025876; Fri, 18 Dec 2015 08:58:33 -0500
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 tBIDwEKG025625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 18 Dec 2015 08:58:18 -0500
Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com [130.9.129.150]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 18 Dec 2015 13:57:56 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.78]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0248.002; Fri, 18 Dec 2015 08:57:56 -0500
From: "DOLLY, MARTIN C" 
To: Richard Hill 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHROEiYt9tG2eQFXECnCpoLN3xbKp7OlCAAgADTIpCAAFmaAIAACymAgAAHQoCAATUxAIAAAN2A//++ShQ=
Date: Fri, 18 Dec 2015 13:57:55 +0000
Message-ID: 
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com> <056701d136a3$e1c49120$a54db360$@ch> <566F1A34.9020402@nostrum.com> <6C827E0C-682C-4484-8F21-20A446746858@shockey.us> <0F2A509D-5DEA-4416-BEEF-3D814C4D02E3@cooperw.in>   <62D8976B-8132-4C80-9656-6A3BD6853EE8@brianrosen.net> <7082DBCA-ABC9-4DFD-90EC-32C5EEEE078C@shockey.us>, <5672FD9B.6060008@nostrum.com> , <00ad01d13993$0e436a90$2aca3fb0$@ch>
In-Reply-To: <00ad01d13993$0e436a90$2aca3fb0$@ch>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-12-18_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310007 definitions=main-1512180257
Archived-At: 
Cc: Steve Donovan , Adam Roach , Alissa Cooper , "modern@ietf.org" , Richard Shockey , "Gorman, Pierce A \[CTO\]" , Brian Rosen 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 18 Dec 2015 13:58:57 -0000

I do not think this work impacts beyond NANP

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards=20
AT&T
Cell: 609-903-3360
Email: md3135@att.com

> On Dec 18, 2015, at 7:53 AM, Richard Hill  wrote:
>=20
> To be clear, I'm not suggesting that this group pause its work or wait fo=
r
> inputs from ITU-T. I'm suggesting that it inform ITU-T of where it stands
> and continue its work. If ITU-T replies, then the group could take that
> input into account in due course.
>=20
> Best,
> Richard
>=20
>> -----Original Message-----
>> From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com]
>> Sent: Friday, December 18, 2015 13:50
>> To: Adam Roach
>> Cc: Richard Shockey; Brian Rosen; Steve Donovan; Richard Hill;
>> modern@ietf.org; Alissa Cooper
>> Subject: Re: [Modern] Problem statement draft as working group document
>>=20
>> Beyond persevering regardless of input and feedback, were there other
>> lessons learned in CODEC that could be applied in this working group?
>>=20
>> Rich Hill's suggestion that learning requirements through an ITU study
>> group could be beneficial seems logical.
>>=20
>> I'm not suggesting this as a stall tactic.  I'm suggesting that MODERN
>> is taking on a global challenge and could benefit from Rich's
>> suggestion.  Are there good reasons to ignore it?
>>=20
>> Sent from my iPad
>>=20
>>>> On Dec 17, 2015, at 12:23 PM, Adam Roach  wrote:
>>>>=20
>>>> On 12/17/15 11:57, Richard Shockey wrote:
>>>> RS> Which some of us dispute. I really really believe that E.164
>> numbering allocation is not within the Expertise of the IETF.
>>>=20
>>> An incredibly congruent objection was raised by several parties in
>> the chartering of CODEC. The result of proceeding anyway was
>> objectively and subjectively the best audio codec ever produced.
>>>=20
>>> /a
>>>=20
>>> _______________________________________________
>>> Modern mailing list
>>> Modern@ietf.org
>>> https://www.ietf.org/mailman/listinfo/modern
>>=20
>> ________________________________
>> Switch to Sprint and save 50% on Verizon, AT&T or T-Mobile rates. Your
>> savings are guaranteed until 2018! Available on most plans. Limited
>> time offer. Exclusions and restrictions apply. See
>> sprint.com/save50 for details.
>>=20
>> ________________________________
>>=20
>> This e-mail may contain Sprint proprietary information intended for the
>> sole use of the recipient(s). Any use by others is prohibited. If you
>> are not the intended recipient, please contact the sender and delete
>> all copies of the message.
>=20
>=20
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern


From nobody Fri Dec 18 06: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 7D2661B364C for ; Fri, 18 Dec 2015 06:02:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZDWSOUh8q5Y for ; Fri, 18 Dec 2015 06:02:31 -0800 (PST)
Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0640E1B3431 for ; Fri, 18 Dec 2015 06:02:30 -0800 (PST)
Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBIE2IxC021654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 18 Dec 2015 15:02:19 +0100
Received: from RHillNew (adsl-178-38-52-133.adslplus.ch [178.38.52.133]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBIE2FKw009490; Fri, 18 Dec 2015 15:02:16 +0100
From: "Richard Hill" 
To: "'DOLLY, MARTIN C'" 
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com> <056701d136a3$e1c49120$a54db360$@ch> <566F1A34.9020402@nostrum.com> <6C827E0C-682C-4484-8F21-20A446746858@shockey.us> <0F2A509D-5DEA-4416-BEEF-3D814C4D02E3@cooperw.in>   <62D8976B-8132-4C80-9656-6A3BD6853EE8@brianrosen.net> <7082DBCA-ABC9-4DFD-90EC-32C5EEEE078C@shockey.us>, <5672FD9B.6060008@nostrum.com> , <00ad01d13993$0e436a90$2aca3fb0$@ch> 
In-Reply-To: 
Date: Fri, 18 Dec 2015 15:02:17 +0100
Message-ID: <016601d1399c$b5eee9f0$21ccbdd0$@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: AQHROEiYt9tG2eQFXECnCpoLN3xbKp7OlCAAgADTIpCAAFmaAIAACymAgAAHQoCAATUxAIAAAN2A//++ShSAAAEKkA==
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: 'Steve Donovan' , 'Adam Roach' , 'Alissa Cooper' , modern@ietf.org, 'Richard Shockey' , "'Gorman, Pierce A \[CTO\]'" , 'Brian Rosen' 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 18 Dec 2015 14:02:33 -0000

NANP involves several countries other than the USA.  Should they be
encouraged to participate in the work?

Best,
Richard

> -----Original Message-----
> From: DOLLY, MARTIN C [mailto:md3135@att.com]
> Sent: Friday, December 18, 2015 14:58
> To: Richard Hill
> Cc: Gorman, Pierce A [CTO]; Adam Roach; Steve Donovan; Brian Rosen;
> modern@ietf.org; Alissa Cooper; Richard Shockey
> Subject: Re: [Modern] Problem statement draft as working group document
> 
> I do not think this work impacts beyond NANP
> 
> Martin C Dolly
> Lead Member of Technical Staff
> Core & Government/Regulatory Standards
> AT&T
> Cell: 609-903-3360
> Email: md3135@att.com
> 
> > On Dec 18, 2015, at 7:53 AM, Richard Hill  wrote:
> >
> > To be clear, I'm not suggesting that this group pause its work or
> wait
> > for inputs from ITU-T. I'm suggesting that it inform ITU-T of where
> it
> > stands and continue its work. If ITU-T replies, then the group could
> > take that input into account in due course.
> >
> > Best,
> > Richard
> >
> >> -----Original Message-----
> >> From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com]
> >> Sent: Friday, December 18, 2015 13:50
> >> To: Adam Roach
> >> Cc: Richard Shockey; Brian Rosen; Steve Donovan; Richard Hill;
> >> modern@ietf.org; Alissa Cooper
> >> Subject: Re: [Modern] Problem statement draft as working group
> >> document
> >>
> >> Beyond persevering regardless of input and feedback, were there
> other
> >> lessons learned in CODEC that could be applied in this working
> group?
> >>
> >> Rich Hill's suggestion that learning requirements through an ITU
> >> study group could be beneficial seems logical.
> >>
> >> I'm not suggesting this as a stall tactic.  I'm suggesting that
> >> MODERN is taking on a global challenge and could benefit from Rich's
> >> suggestion.  Are there good reasons to ignore it?
> >>
> >> Sent from my iPad
> >>
> >>>> On Dec 17, 2015, at 12:23 PM, Adam Roach  wrote:
> >>>>
> >>>> On 12/17/15 11:57, Richard Shockey wrote:
> >>>> RS> Which some of us dispute. I really really believe that E.164
> >> numbering allocation is not within the Expertise of the IETF.
> >>>
> >>> An incredibly congruent objection was raised by several parties in
> >> the chartering of CODEC. The result of proceeding anyway was
> >> objectively and subjectively the best audio codec ever produced.
> >>>
> >>> /a
> >>>
> >>> _______________________________________________
> >>> Modern mailing list
> >>> Modern@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/modern
> >>
> >> ________________________________
> >> Switch to Sprint and save 50% on Verizon, AT&T or T-Mobile rates.
> >> Your savings are guaranteed until 2018! Available on most plans.
> >> Limited time offer. Exclusions and restrictions apply. See
> >> sprint.com/save50 for details.
> >>
> >> ________________________________
> >>
> >> This e-mail may contain Sprint proprietary information intended for
> >> the sole use of the recipient(s). Any use by others is prohibited.
> If
> >> you are not the intended recipient, please contact the sender and
> >> delete all copies of the message.
> >
> >
> > _______________________________________________
> > Modern mailing list
> > Modern@ietf.org
> > https://www.ietf.org/mailman/listinfo/modern



From nobody Fri Dec 18 14:56: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 8845E1B39D8 for ; Fri, 18 Dec 2015 14:56:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3dbRET64ny9 for ; Fri, 18 Dec 2015 14:56:46 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0102.outbound.protection.outlook.com [207.46.100.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 951FF1B39D1 for ; Fri, 18 Dec 2015 14:56:45 -0800 (PST)
Received: from BL2FFO11OLC010.protection.gbl (10.173.160.30) by BL2FFO11HUB024.protection.gbl (10.173.161.48) with Microsoft SMTP Server (TLS) id 15.1.355.15; Fri, 18 Dec 2015 22:56:44 +0000
Authentication-Results: spf=pass (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; brianrosen.net; dkim=none (message not signed) header.d=none;brianrosen.net; dmarc=bestguesspass action=none header.from=sprint.com;
Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.38 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.38; helo=plsapdm2.corp.sprint.com;
Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BL2FFO11OLC010.mail.protection.outlook.com (10.173.160.154) with Microsoft SMTP Server (TLS) id 15.1.355.15 via Frontend Transport; Fri, 18 Dec 2015 22:56:43 +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 tBIJmWTT029476;  Fri, 18 Dec 2015 16:56:42 -0600
Received: from plswe13m07.ad.sprint.com (plswe13m07.corp.sprint.com [144.229.214.26]) by plsapdm2.corp.sprint.com with ESMTP id 1ytsex51n6-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 18 Dec 2015 16:56:42 -0600
Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 18 Dec 2015 16:56:41 -0600
Received: from PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed]) by PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed%24]) with mapi id 15.00.1076.000; Fri, 18 Dec 2015 16:56:41 -0600
From: "Gorman, Pierce A [CTO]" 
To: Richard Hill , "'DOLLY, MARTIN C'" 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHROEiYKCigIa6jakmAIZNM6lCGV57OlCAAgADTIpCAAGpeAIAACymAgAAHQYCAANCdQoAAAH5AgAB3DoCAAAE5gIAAKZHA
Date: Fri, 18 Dec 2015 22:56:41 +0000
Message-ID: <0a9cfb276de14324ba975e9fabe438bf@PLSWE13M08.ad.sprint.com>
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com> <056701d136a3$e1c49120$a54db360$@ch> <566F1A34.9020402@nostrum.com> <6C827E0C-682C-4484-8F21-20A446746858@shockey.us> <0F2A509D-5DEA-4416-BEEF-3D814C4D02E3@cooperw.in>   <62D8976B-8132-4C80-9656-6A3BD6853EE8@brianrosen.net> <7082DBCA-ABC9-4DFD-90EC-32C5EEEE078C@shockey.us>, <5672FD9B.6060008@nostrum.com> , <00ad01d13993$0e436a90$2aca3fb0$@ch>  <016601d1399c$b5eee9f0$21ccbdd0$@ch>
In-Reply-To: <016601d1399c$b5eee9f0$21ccbdd0$@ch>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.123.104.26]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC010; 1:xUUuoCXwwrqU18zUm9qO1yilhxNwq516NKTNXBhlg2uSvC6tRHG+CYdNvGtfVWnIdv7NswaeHQLRAF+Gu/KcC7s4sJ5qMGfVKpGaA8K31wkjTxNBXjut/D4VT1wQFWjxupJnnodgd12KfovNeiOhEJrkWK+aa3HXOiZh8f/7iNCzYyotW795vkn+FJcIdMP/VKLouPmmY6IhTLEkj3WvayW30rMNIf8CHxiSZLp0p1s0q1xiSlqyz7KBoW5jGXi+2EcsgQvxD0FxZ5zZcpl2WyT7+SaYtF0u4TrcJi+UA87ua9wSN6lTqQ13mKM3R/ODwvtWHZTXEMYrr1nilAyXv1LgjYoMKkbRKj1Bd/aZ0sxsCqTboA9BRuzIOKRDrBYhuIXtn3DcFB00PxKjQFOWEw==
X-Forefront-Antispam-Report: CIP:144.230.172.38; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(479174004)(189002)(377454003)(24454002)(199003)(13464003)(252514010)(5001770100001)(47776003)(93886004)(76176999)(50986999)(19580395003)(50466002)(325944007)(54356999)(15395725005)(86362001)(19580405001)(46406003)(87936001)(5003600100002)(5003630100001)(97756001)(24736003)(11100500001)(5001960100002)(586003)(102836003)(3846002)(97736004)(5008740100001)(5004730100002)(189998001)(6116002)(6806005)(33646002)(106116001)(15975445007)(23726003)(5250100002)(108616004)(1096002)(1220700001)(81156007)(106466001)(2950100001)(2900100001)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB024; H:plsapdm2.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB024; 2:CMpf5DrzvhzFqx1N4C3UJxD19I6VaA1CasQYA7nR/IO32YEUAvToj6sHOR0Fmp6l9hjQV5DeIHtv8hmtu7Rp+T2FGhlB/h5+UTFAMfWAlWM9Mn2ojVRrFoVNj6RfIGTc4qSTRLS0tMwrD1ebQIraWA==; 3:lJYrixIzOPY9JrNICRZ/y2XyvxUcOKV5VYDWFq2kBvkmTfDda7riI6FmrXGDNt5fTVPKlHwoBhogHtriYNbVfhjktprIIjPGZ7FOzVuh8NGE4OkNiZsWoA3o3IDBzHrZLD5aqoB8MOlEmgPf+6in8Ik2MkbB37pvQPcQeVG1BT1KYkmU8VymiVGN2wlEauiH9QUEVeFyC/IfB5o8Qq81++x3SEdljZeMt0jCKGjciLnxsCNkIijXCHIaaqMmNBBTfnvHIfzz9gYaxArL03OsBQ==; 25:UhMu2YPTRpOwRgZ5sGMW7x4m5j55lmjO5mjvN+kqJnT6aWjwLnMkFuKnfFJ7Nwniy2ZxztbVND9274hQNHMB0GqAm7achhjIIFGqQBYHoo0TsFuEJ5ztfBoHCWh/EngAe8yJyy57eGwdR6+MaU7Qi3JvrZcFNhzDAi+lHIhSlKe8qCQaNRKx/aRpN6daxT/8CYxrmz0cUAqivcB1VqZd7kbZCgIQX/hMvL190f3U+Ubd8d8YqrAD1y6wvDthzTUxw8Z3dVrcR0mWx6PWrn2EcQ==
X-Exchange-Antispam-Report-Test: UriScan:; BCL:0; PCL:0; RULEID:(8251501002);  SRVR:BL2FFO11HUB024; UriScan:(18430343700868)(97927398514766); 
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB024; 20:SAMJVuzO4RPyovORYTaFbxzLs/UWuYKHsRGRzTlX7MpAoRvKw72JjM2+XvP03nuAj+258SKYOvn5WVY4uX4eF8Ve+sx6TjiyuBqvJK6F/Rc0HCStgHOkECz/TO7PaJgrEyKB1Xf+ZUv5RcYsunn5tr4OKZ5ufGN1zONm1ygEpxlvP3oRJRiLNX77l8nOuGaq52mTRSdTzOD4YXYjn2aRZ40WbLnnc7msxVph7+vhWA4BjWun+hLB56q0wWElpZDD; 4:0IA7xpv2C/eawWTJxotBNePKa/u2+daJK28cngILbDWkJ9ANMHx5i5aiCfsVKDLZB2mDFyNuhfi5MiQdQp1irnqzf4FVrjk4NS7yEjjVmlbbMGYgMif0Fk7A4gppjs7OTrO2m4/MyhN2Os/qt87CbM/QrV0KwVo0eG+RKdQ3NFyIOYjqIVVFFAah+RfYb+IPwmTl6J7iDfsReM8XSKFmVujJc76nnCwGbfRfgnJk+hDWTguyU5SXRYy8dWIJNenTsf1oZJz803ZEFnDIFOuEOniEVBP7R+4qktE3o3DocN1Q2V6c60a5NyhbW2tEOpoEra4FQuqIiGerh3IjDt6A3AJ+AELlle9FrjstLfSANW5ASLKT/LhLh/ZF/m4c9kbk9/cjekZw9w1yIv7DilcIfaYJsLMb8udmSJxdUl69jtoglECbfU300xlNEXQu9nqLXFh6+W9DSq6UWg15N+6UQQ==
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(10201501046)(3002001); SRVR:BL2FFO11HUB024; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB024; 
X-Forefront-PRVS: 07943272E1
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2FFO11HUB024; 23:jbTnt0MLAqXjxGFJTWCJelnYrRIoyprxKfg3k/dT?= =?us-ascii?Q?RQor2X+NcVcnEE2Ak+3xGkOB8LGieqWAAVXkdQYLEjPfkPkCmVruLO8Hh6ao?= =?us-ascii?Q?yRSxlUYYSBb/RoelmXj9fejTyDZFEC3gmPd89l1+QR7QbHAMN0XCFjasOiuo?= =?us-ascii?Q?GO42Ay2p0dx63Pp3LOwF33cbPTpUcS+N4p1ZR8hCl7T1NANufDEATrasyOCI?= =?us-ascii?Q?kLBxSxzKGOKUTsC0XpgzRDDylITQTTRvq4iNZth9BzYpHqj8UcP5RdUAITmE?= =?us-ascii?Q?wiFNEuX+WKNOARy9T2Hfl5PKN5zcvFrKXzKMeY8gVgmr+GgXNx2wVCFmWc9y?= =?us-ascii?Q?UH0k0Sev3cZQYRKA2IdFgEPpZaKiqzk5hYOrs8C77lQi2CAHRD52GT3m8RLh?= =?us-ascii?Q?jhjdP9vGhw78bCH37u9YFoT8rz7jFDmWkLxxvffhOm7fV1Zd6p9V38XxTqbL?= =?us-ascii?Q?NqgSjWKygnD3F+P6O6i4iBt8YkTg8KYcPcLUl4s0+ZpLvjzcrqyv9x6ZdvCo?= =?us-ascii?Q?Dc5DnNdOTJnEH81zpe8xFkGZdz/N9UZ3KOyOnaezsW92ZFlhIbMu7wkKPi0s?= =?us-ascii?Q?bdx+tcsOgzEVt6cYyMnX4e6nf4+d++9TMhWApIuW3xEvLeGnKRngrnjdLYvc?= =?us-ascii?Q?Lv0t4Pw5pFxQn+rMUW6P8pUHONKryJmab7OGwDEFx5+7OM95D5e6IS6iUacX?= =?us-ascii?Q?nKh5+fPwaT0O6HkiXb0uJnhlGsITzfES8GuUMXAiswuYx2nwWA4kt6VLwZyU?= =?us-ascii?Q?ANxqQ3qHoOfBjp8ifDjWQp65tcDuNgCKK9Zn/YRqbf4+YljxEBy9Xt3bQ1lt?= =?us-ascii?Q?rCX02yexLa2gON2r73hIHm0yjLAkjTiJiSqfKLtC1vnj4+8X/0/eSUkQpCWD?= =?us-ascii?Q?/9ry2ZI7QrtBKKOTqIuE6jEEsNOiZldo18N52FyOqFIzMx+EgbJIwVemwrvb?= =?us-ascii?Q?qFwsH7EnFKi7uFCuHjxCVuva2uDPFcybsDBJa/JFZkecibN905Mzl9Nxg1b2?= =?us-ascii?Q?C8sGa3rXw+4vq0zkvJ1dUgym8usv8RA+CYqwVK0e5PotmJ59cynugN1Bp+pM?= =?us-ascii?Q?dKwVz5iCdfq0I5qRxXnjxWOdJqYyO6ZC3ZJQ3SS4B+ysukChdaTdY3mcqQA7?= =?us-ascii?Q?yQgPaDK9o1/7htMGdmUcAnqIkGy/uSdDJTSwUsu3zXwgnbAUkvlTCFkxHZ4q?= =?us-ascii?Q?3LjtJinyA9cuwUO707XDe6w7+rBGyq7WHOQhj5diluRQvfrTANEQeGkjgH55?= =?us-ascii?Q?K1CGoc41VLTovvUhMg+HSIvc+Rcl8xvcIshdEmvKO18+jot+raM/5IJZbv2M?= =?us-ascii?Q?f0SlPckeiID2ktVSgfFIRxBHwDkvF2Ig/MB1S8pPwzb/6kQnMMWIKPiC5ndp?= =?us-ascii?Q?QcoY0kU+zT+cKRAuOf7kWMxwSqk=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB024; 5:IX81vaW7VC0Rnlcard2FBC7hGDLB8bayNR+L2HH/9bPt4Tcnz7RE76symq90E2Q5FnwzA3UMzzSAB0tiOYRDAYc3nkD0OqvT8yK2ePtp2Eau71/vaJ58J2wqnuqHJfJPTa5KiC0lR8JEfyYgjQd3Aw==; 24:2hMDZV+mppqRhN4CiRc8CQRgRsSgE1YGsSJlIsPVup023+oUr5qIjHPLjZe6wrV9TrZDgtXH/T5PN/0pEjky0hSdFWg9c+/WaAzlH39uyV8=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: sprint.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2015 22:56:43.4539 (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: BL2FFO11HUB024
Archived-At: 
Cc: 'Steve Donovan' , 'Adam Roach' , 'Alissa Cooper' , "modern@ietf.org" , 'Richard Shockey' , 'Brian Rosen' 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 18 Dec 2015 22:56:50 -0000

You bring up something I wondered about.

I'm new to how things proceed in standards development but was hopeful your=
 comment about an ITU-T Study Group could provide some things I thought wou=
ld be of special value to the work in MODERN.

First, a dictionary or other compendium of all of the impacted regulatory n=
umbering authority bodies and some high-level assessment and/or overview of=
 their assignment and management processes would be very helpful.

Second, a similar comprehensive work identifying all of the variations in t=
ypes of numbers, any assignment-specific requirements (e.g., toll free shou=
ld be instructive) by country would be good.

Finally, a list of points of contact for number administration and routing =
information management for each of the registered carriers in the world.  (=
MODERN will enjoy more help than it has now.)

For the first two, there will be a lot of commonalities, but there will ver=
y likely be numerous requirements and challenges (and opportunities) identi=
fied which should greatly benefit the development of the MODERN problem sta=
tement(s).

While this seems prudent to me, it might also be outside of the scope of th=
e IETF or any SDO to use this approach.  One of my job responsibilities alm=
ost 30 years ago was database development for routing translations and prem=
ise-based user-defined systems succeeded where visionary approaches failed,=
 so I am offering my view of long-ago hard-won experience.

Pierce

-----Original Message-----
From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard Hill
Sent: December 18, 2015 8:02 AM
To: 'DOLLY, MARTIN C' 
Cc: 'Steve Donovan' ; 'Adam Roach' ; 'Alissa Cooper' ; modern@ietf.org; 'Richard Shocke=
y' ; Gorman, Pierce A [CTO] ;=
 'Brian Rosen' 
Subject: Re: [Modern] Problem statement draft as working group document

NANP involves several countries other than the USA.  Should they be encoura=
ged to participate in the work?

Best,
Richard

> -----Original Message-----
> From: DOLLY, MARTIN C [mailto:md3135@att.com]
> Sent: Friday, December 18, 2015 14:58
> To: Richard Hill
> Cc: Gorman, Pierce A [CTO]; Adam Roach; Steve Donovan; Brian Rosen;
> modern@ietf.org; Alissa Cooper; Richard Shockey
> Subject: Re: [Modern] Problem statement draft as working group
> document
>
> I do not think this work impacts beyond NANP
>
> Martin C Dolly
> Lead Member of Technical Staff
> Core & Government/Regulatory Standards AT&T
> Cell: 609-903-3360
> Email: md3135@att.com
>
> > On Dec 18, 2015, at 7:53 AM, Richard Hill  wrote:
> >
> > To be clear, I'm not suggesting that this group pause its work or
> wait
> > for inputs from ITU-T. I'm suggesting that it inform ITU-T of where
> it
> > stands and continue its work. If ITU-T replies, then the group could
> > take that input into account in due course.
> >
> > Best,
> > Richard
> >
> >> -----Original Message-----
> >> From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com]
> >> Sent: Friday, December 18, 2015 13:50
> >> To: Adam Roach
> >> Cc: Richard Shockey; Brian Rosen; Steve Donovan; Richard Hill;
> >> modern@ietf.org; Alissa Cooper
> >> Subject: Re: [Modern] Problem statement draft as working group
> >> document
> >>
> >> Beyond persevering regardless of input and feedback, were there
> other
> >> lessons learned in CODEC that could be applied in this working
> group?
> >>
> >> Rich Hill's suggestion that learning requirements through an ITU
> >> study group could be beneficial seems logical.
> >>
> >> I'm not suggesting this as a stall tactic.  I'm suggesting that
> >> MODERN is taking on a global challenge and could benefit from
> >> Rich's suggestion.  Are there good reasons to ignore it?
> >>
> >> Sent from my iPad
> >>
> >>>> On Dec 17, 2015, at 12:23 PM, Adam Roach  wrote:
> >>>>
> >>>> On 12/17/15 11:57, Richard Shockey wrote:
> >>>> RS> Which some of us dispute. I really really believe that E.164
> >> numbering allocation is not within the Expertise of the IETF.
> >>>
> >>> An incredibly congruent objection was raised by several parties in
> >> the chartering of CODEC. The result of proceeding anyway was
> >> objectively and subjectively the best audio codec ever produced.
> >>>
> >>> /a
> >>>
> >>> _______________________________________________
> >>> Modern mailing list
> >>> Modern@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/modern
> >>
> >> ________________________________
> >> Switch to Sprint and save 50% on Verizon, AT&T or T-Mobile rates.
> >> Your savings are guaranteed until 2018! Available on most plans.
> >> Limited time offer. Exclusions and restrictions apply. See
> >> sprint.com/save50 for details.
> >>
> >> ________________________________
> >>
> >> This e-mail may contain Sprint proprietary information intended for
> >> the sole use of the recipient(s). Any use by others is prohibited.
> If
> >> you are not the intended recipient, please contact the sender and
> >> delete all copies of the message.
> >
> >
> > _______________________________________________
> > Modern mailing list
> > Modern@ietf.org
> > https://www.ietf.org/mailman/listinfo/modern


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

________________________________
Switch to Sprint and save 50% on Verizon, AT&T or T-Mobile rates. Your savi=
ngs are guaranteed until 2018! Available on most plans. Limited time offer.=
 Exclusions and restrictions apply. See sprint.com/save50 for details.

________________________________

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


From nobody Sat Dec 19 02:23: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 8A3831A8820 for ; Sat, 19 Dec 2015 02:23:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0UNPNIuDsBh for ; Sat, 19 Dec 2015 02:23:51 -0800 (PST)
Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877711A87F1 for ; Sat, 19 Dec 2015 02:23:51 -0800 (PST)
Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBJANYMc004554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 19 Dec 2015 11:23:34 +0100
Received: from RHillNew (adsl-178-38-53-93.adslplus.ch [178.38.53.93]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id tBJANT6A001637; Sat, 19 Dec 2015 11:23:29 +0100
From: "Richard Hill" 
To: "'Gorman, Pierce A [CTO]'" , "'DOLLY, MARTIN C'" 
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com> <056701d136a3$e1c49120$a54db360$@ch> <566F1A34.9020402@nostrum.com> <6C827E0C-682C-4484-8F21-20A446746858@shockey.us> <0F2A509D-5DEA-4416-BEEF-3D814C4D02E3@cooperw.in>   <62D8976B-8132-4C80-9656-6A3BD6853EE8@brianrosen.net> <7082DBCA-ABC9-4DFD-90EC-32C5EEEE078C@shockey.us>, <5672FD9B.6060008@nostrum.com> , <00ad01d13993$0e436a90$2aca3fb0$@ch>  <016601d1399c$b5eee9f0$21ccbdd0$@ch> <0a9cfb276de14324ba975e9fabe438bf@PLSWE13M08.ad.sprint.com>
In-Reply-To: <0a9cfb276de14324ba975e9fabe438bf@PLSWE13M08.ad.sprint.com>
Date: Sat, 19 Dec 2015 11:23:29 +0100
Message-ID: <004e01d13a47$508f1b60$f1ad5220$@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: AQHROEiYKCigIa6jakmAIZNM6lCGV57OlCAAgADTIpCAAGpeAIAACymAgAAHQYCAANCdQoAAAH5AgAB3DoCAAAE5gIAAKZHAgAC9wqA=
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: 'Steve Donovan' , 'Adam Roach' , 'Alissa Cooper' , modern@ietf.org, 'Richard Shockey' , 'Brian Rosen' 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 19 Dec 2015 10:23:55 -0000

Please see below.

Thanks and best,
Richard

> -----Original Message-----
> From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com]
> Sent: Friday, December 18, 2015 23:57
> To: Richard Hill; 'DOLLY, MARTIN C'
> Cc: 'Steve Donovan'; 'Adam Roach'; 'Alissa Cooper'; modern@ietf.org;
> 'Richard Shockey'; 'Brian Rosen'
> Subject: RE: [Modern] Problem statement draft as working group document
> 
> You bring up something I wondered about.
> 
> I'm new to how things proceed in standards development but was hopeful
> your comment about an ITU-T Study Group could provide some things I
> thought would be of special value to the work in MODERN.
> 
> First, a dictionary or other compendium of all of the impacted
> regulatory numbering authority bodies

As others have pointed out, a numbering authority would only be impacted if
it agreed to use the protocols developed in this group. Almost all of the
world's numbering authorities are represented in ITU-T. You can find the
coordinates of the regulator by going to the individual country page from
the overall country listing at:

 
https://www.itu.int/online/mm/scripts/mm.list?_search=ITUstates&_languageid=
1 

A variety of information on international numbering resources (including
E.164 numbers and national numbering plans) is available at:

  http://www.itu.int/en/ITU-T/inr/Pages/default.aspx 

ITU-D publishes a "regulatory tracker" that includes information such as
whether VoIP is allowed, see:

  http://www.itu.int/en/ITU-D/Regulatory-Market/tracker/Pages/default.aspx 

An overview of the regulatory policies in each country is published at:

  http://www.itu.int/net4/itu-d/icteye/CountryProfile.aspx 

However, I don't see anything specific there about number allocation
policies or regulations.

> and some high-level assessment
> and/or overview of their assignment and management processes would be
> very helpful.

Maybe somebody has done an overall synthesis, but if so I'm not aware of it.

The EU Framework Directive has an article on Numbering, Naming and
Addressing (Art. 10). Although it does not explicitly say so, to me it seems
to imply that numbers can be assigned only to providers, not to end-users.
The directive is at:

 
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2002:108:0033:005
0:EN:PDF 

> 
> Second, a similar comprehensive work identifying all of the variations
> in types of numbers, any assignment-specific requirements (e.g., toll
> free should be instructive) by country would be good.

You will find much of that in the ITU's compilation of national numbering
plans, at:

  http://www.itu.int/oth/T0202.aspx?parent=T0202 

There is a specific page for emergency numbers, at:

 http://www.itu.int/net/itu-t/inrdb/e129_important_numbers.aspx 

> 
> Finally, a list of points of contact for number administration

You will find that in the listing of ITU members referenced above.

> and
> routing information management for each of the registered carriers in
> the world.  

The concept of "registered carriers" no longer exists in many countries. A
list of carriers that are considered to be in that category is published at:

  http://www.itu.int/en/ITU-T/inr/Pages/roa.aspx 

However, I'm not aware of any publicly available compilation of routing
information for telephony. As far as I know, operators maintain their own
proprietary routing tables.

>(MODERN will enjoy more help than it has now.)
> 
> For the first two, there will be a lot of commonalities, but there will
> very likely be numerous requirements and challenges (and opportunities)
> identified which should greatly benefit the development of the MODERN
> problem statement(s).
> 
> While this seems prudent to me, it might also be outside of the scope
> of the IETF or any SDO to use this approach.  One of my job
> responsibilities almost 30 years ago was database development for
> routing translations and premise-based user-defined systems succeeded
> where visionary approaches failed, so I am offering my view of long-ago
> hard-won experience.
> 
> Pierce
> 
> -----Original Message-----
> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard Hill
> Sent: December 18, 2015 8:02 AM
> To: 'DOLLY, MARTIN C' 
> Cc: 'Steve Donovan' ; 'Adam Roach'
> ; 'Alissa Cooper' ;
> modern@ietf.org; 'Richard Shockey' ; Gorman, Pierce
> A [CTO] ; 'Brian Rosen' 
> Subject: Re: [Modern] Problem statement draft as working group document
> 
> NANP involves several countries other than the USA.  Should they be
> encouraged to participate in the work?
> 
> Best,
> Richard
> 
> > -----Original Message-----
> > From: DOLLY, MARTIN C [mailto:md3135@att.com]
> > Sent: Friday, December 18, 2015 14:58
> > To: Richard Hill
> > Cc: Gorman, Pierce A [CTO]; Adam Roach; Steve Donovan; Brian Rosen;
> > modern@ietf.org; Alissa Cooper; Richard Shockey
> > Subject: Re: [Modern] Problem statement draft as working group
> > document
> >
> > I do not think this work impacts beyond NANP
> >
> > Martin C Dolly
> > Lead Member of Technical Staff
> > Core & Government/Regulatory Standards AT&T
> > Cell: 609-903-3360
> > Email: md3135@att.com
> >
> > > On Dec 18, 2015, at 7:53 AM, Richard Hill  wrote:
> > >
> > > To be clear, I'm not suggesting that this group pause its work or
> > wait
> > > for inputs from ITU-T. I'm suggesting that it inform ITU-T of where
> > it
> > > stands and continue its work. If ITU-T replies, then the group
> could
> > > take that input into account in due course.
> > >
> > > Best,
> > > Richard
> > >
> > >> -----Original Message-----
> > >> From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com]
> > >> Sent: Friday, December 18, 2015 13:50
> > >> To: Adam Roach
> > >> Cc: Richard Shockey; Brian Rosen; Steve Donovan; Richard Hill;
> > >> modern@ietf.org; Alissa Cooper
> > >> Subject: Re: [Modern] Problem statement draft as working group
> > >> document
> > >>
> > >> Beyond persevering regardless of input and feedback, were there
> > other
> > >> lessons learned in CODEC that could be applied in this working
> > group?
> > >>
> > >> Rich Hill's suggestion that learning requirements through an ITU
> > >> study group could be beneficial seems logical.
> > >>
> > >> I'm not suggesting this as a stall tactic.  I'm suggesting that
> > >> MODERN is taking on a global challenge and could benefit from
> > >> Rich's suggestion.  Are there good reasons to ignore it?
> > >>
> > >> Sent from my iPad
> > >>
> > >>>> On Dec 17, 2015, at 12:23 PM, Adam Roach 
> wrote:
> > >>>>
> > >>>> On 12/17/15 11:57, Richard Shockey wrote:
> > >>>> RS> Which some of us dispute. I really really believe that E.164
> > >> numbering allocation is not within the Expertise of the IETF.
> > >>>
> > >>> An incredibly congruent objection was raised by several parties
> in
> > >> the chartering of CODEC. The result of proceeding anyway was
> > >> objectively and subjectively the best audio codec ever produced.
> > >>>
> > >>> /a
> > >>>
> > >>> _______________________________________________
> > >>> Modern mailing list
> > >>> Modern@ietf.org
> > >>> https://www.ietf.org/mailman/listinfo/modern
> > >>
> > >> ________________________________
> > >> Switch to Sprint and save 50% on Verizon, AT&T or T-Mobile rates.
> > >> Your savings are guaranteed until 2018! Available on most plans.
> > >> Limited time offer. Exclusions and restrictions apply. See
> > >> sprint.com/save50 for details.
> > >>
> > >> ________________________________
> > >>
> > >> This e-mail may contain Sprint proprietary information intended
> for
> > >> the sole use of the recipient(s). Any use by others is prohibited.
> > If
> > >> you are not the intended recipient, please contact the sender and
> > >> delete all copies of the message.
> > >
> > >
> > > _______________________________________________
> > > Modern mailing list
> > > Modern@ietf.org
> > > https://www.ietf.org/mailman/listinfo/modern
> 
> 
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern
> 
> ________________________________
> Switch to Sprint and save 50% on Verizon, AT&T or T-Mobile rates. Your
> savings are guaranteed until 2018! Available on most plans. Limited
> time offer. Exclusions and restrictions apply. See
> sprint.com/save50 for details.
> 
> ________________________________
> 
> This e-mail may contain Sprint proprietary information intended for the
> sole use of the recipient(s). Any use by others is prohibited. If you
> are not the intended recipient, please contact the sender and delete
> all copies of the message.



From nobody Sat Dec 19 03:57:05 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBD81A88B6 for ; Sat, 19 Dec 2015 03:57:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.622
X-Spam-Level: 
X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OA-VysYNgcOx for ; Sat, 19 Dec 2015 03:57:01 -0800 (PST)
Received: from mail-lf0-x245.google.com (mail-lf0-x245.google.com [IPv6:2a00:1450:4010:c07::245]) (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 DC1A41A88AF for ; Sat, 19 Dec 2015 03:57:00 -0800 (PST)
Received: by mail-lf0-x245.google.com with SMTP id z124so51679680lfa.1 for ; Sat, 19 Dec 2015 03:57:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=e-c-group-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rSw+Lcpyk8keD1JSF/T2kCihWvuVPBA8K/wBxBkrtWA=; b=WAWkPcaN5TevBopV4t1b7vUYxFErdl077hc7YtOzSSidkycscRglmXuE2Qb7kdceZv vIrzqh/g9OnGnNchdFpBCqIOXAM/eZvS5PprZxUt+0857ud+iFU+pCnh/pnqxoECO9m1 sMBKhaH7gt997ayjznp5pRXe2zzHfGVR3PsspPYeRyKIPr2OP+u2sNsl6SO5bOlwcaEt /m56L0O5vKemUxeLmw7bYxpsvs0kuihAae1Js+RLMMjNlrjetXv0zLy/nmeSxt+QlUXK PZLHRg2sF8RglIY0gzv5b9Lghxk0Mb3AghhvVWXX4IsbBdEcsQA/+YHwKIdDQehj4nVT kTww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rSw+Lcpyk8keD1JSF/T2kCihWvuVPBA8K/wBxBkrtWA=; b=N+f9jbM4BWvNZOtZ/r4Lvq5OyVE19TxF/4r6D3udO51t+KInaI/ZrtyxQEz7rafEGz wfNESJLH1azaPJXRN+o65LbKTZEWbXQ2PT7SfDgoPyaIIQkUYj+ehz2EuJ+Kpn5En/Cc 6SdRLsYpyRlVEaCxn2cEc1edTd7nYtpM+LJx1IWrkTxBb6QEZk7fiD2/V1fTEz66mgNa BasNryhqxIQUkV6gIPBdPsD3uc8KKw0v2RKJRHBXi+HZWvO56FtJdpI7dThrcevCMCnl BO6f3QcSwgzIw/4y8GTTbfwDVLh/0vevIW+XLiDJVx1pE93uFjqqOduZoPkOds7MBci2 EkMA==
X-Gm-Message-State: ALoCoQnxGlJFQCRCSDsWJj0r8OuZX/1fzA6KNGQNezU2JIySp9LXMAEXdc/HTzQpweRWkv41EB4b9GxuqhiB0gPcktq1tvEobIZ1KFAS8Atfte0svLPNnRo=
MIME-Version: 1.0
X-Received: by 10.112.166.33 with SMTP id zd1mr2557522lbb.113.1450526218896; Sat, 19 Dec 2015 03:56:58 -0800 (PST)
Received: by 10.114.174.51 with HTTP; Sat, 19 Dec 2015 03:56:58 -0800 (PST)
In-Reply-To: <004e01d13a47$508f1b60$f1ad5220$@ch>
References: <56465BCD.1090602@usdonovans.com> <5669C701.3060604@usdonovans.com> <566F1005.4050302@nostrum.com> <056701d136a3$e1c49120$a54db360$@ch> <566F1A34.9020402@nostrum.com> <6C827E0C-682C-4484-8F21-20A446746858@shockey.us> <0F2A509D-5DEA-4416-BEEF-3D814C4D02E3@cooperw.in>   <62D8976B-8132-4C80-9656-6A3BD6853EE8@brianrosen.net> <7082DBCA-ABC9-4DFD-90EC-32C5EEEE078C@shockey.us> <5672FD9B.6060008@nostrum.com>  <00ad01d13993$0e436a90$2aca3fb0$@ch>  <016601d1399c$b5eee9f0$21ccbdd0$@ch> <0a9cfb276de14324ba975e9fabe438bf@PLSWE13M08.ad.sprint.com> <004e01d13a47$508f1b60$f1ad5220$@ch>
Date: Sat, 19 Dec 2015 06:56:58 -0500
Message-ID: 
From: "Mark R Lindsey, ECG" 
To: Richard Hill 
Content-Type: multipart/alternative; boundary=001a11c37c5403e3e205273ef40d
Archived-At: 
Cc: Steve Donovan , Adam Roach , Alissa Cooper , "modern@ietf.org" , "DOLLY, MARTIN C" , Richard Shockey , "Gorman, Pierce A \[CTO\]" , Brian Rosen 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 19 Dec 2015 11:57:04 -0000

--001a11c37c5403e3e205273ef40d
Content-Type: text/plain; charset=UTF-8

I hear consensus! Proposed alternative problem statement capturing the
mood:


WE DON'T KNOW WHAT WE DON'T KNOW (So let's find out how to find out)

1. We'd like to have Internet protocol support for management, allocation,
assignment etc., of "telephone numbers" worldwide ("The Domain")

2. We know The Domain has existed for 100 years, and takes enormous number
of shapes in Real Networks, some regulatory, some commercial, some technical

3. We don't yet which of these are important enough to bake into a protocol

4. If we make a protocol that's not a good fit for The Domain, we're making
the problem worse because a bad protocol further obfuscates The Domain and
distracts from working protocols of the future

5. Thus the REAL PROBLEM TO BE SOLVED is how to understand enough of
The Domain to have a reasonable chance of making a relevant protocol,
likely to be achieved by actively collecting information from the parties
involved in The Domain



---
Mark R Lindsey, mailto:lindsey@e-c-group.com, tel:+1-229-316-0013,
http://ecg.co/lindsey

On Saturday, December 19, 2015, Richard Hill  wrote:

> Please see below.
>
> Thanks and best,
> Richard
>
> > -----Original Message-----
> > From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com
> ]
> > Sent: Friday, December 18, 2015 23:57
> > To: Richard Hill; 'DOLLY, MARTIN C'
> > Cc: 'Steve Donovan'; 'Adam Roach'; 'Alissa Cooper'; modern@ietf.org
> ;
> > 'Richard Shockey'; 'Brian Rosen'
> > Subject: RE: [Modern] Problem statement draft as working group document
> >
> > You bring up something I wondered about.
> >
> > I'm new to how things proceed in standards development but was hopeful
> > your comment about an ITU-T Study Group could provide some things I
> > thought would be of special value to the work in MODERN.
> >
> > First, a dictionary or other compendium of all of the impacted
> > regulatory numbering authority bodies
>
> As others have pointed out, a numbering authority would only be impacted if
> it agreed to use the protocols developed in this group. Almost all of the
> world's numbering authorities are represented in ITU-T. You can find the
> coordinates of the regulator by going to the individual country page from
> the overall country listing at:
>
>
>
> https://www.itu.int/online/mm/scripts/mm.list?_search=ITUstates&_languageid=
> 1
>
> A variety of information on international numbering resources (including
> E.164 numbers and national numbering plans) is available at:
>
>   http://www.itu.int/en/ITU-T/inr/Pages/default.aspx
>
> ITU-D publishes a "regulatory tracker" that includes information such as
> whether VoIP is allowed, see:
>
>   http://www.itu.int/en/ITU-D/Regulatory-Market/tracker/Pages/default.aspx
>
> An overview of the regulatory policies in each country is published at:
>
>   http://www.itu.int/net4/itu-d/icteye/CountryProfile.aspx
>
> However, I don't see anything specific there about number allocation
> policies or regulations.
>
> > and some high-level assessment
> > and/or overview of their assignment and management processes would be
> > very helpful.
>
> Maybe somebody has done an overall synthesis, but if so I'm not aware of
> it.
>
> The EU Framework Directive has an article on Numbering, Naming and
> Addressing (Art. 10). Although it does not explicitly say so, to me it
> seems
> to imply that numbers can be assigned only to providers, not to end-users.
> The directive is at:
>
>
>
> http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2002:108:0033:005
> 0:EN:PDF
>
> >
> > Second, a similar comprehensive work identifying all of the variations
> > in types of numbers, any assignment-specific requirements (e.g., toll
> > free should be instructive) by country would be good.
>
> You will find much of that in the ITU's compilation of national numbering
> plans, at:
>
>   http://www.itu.int/oth/T0202.aspx?parent=T0202
>
> There is a specific page for emergency numbers, at:
>
>  http://www.itu.int/net/itu-t/inrdb/e129_important_numbers.aspx
>
> >
> > Finally, a list of points of contact for number administration
>
> You will find that in the listing of ITU members referenced above.
>
> > and
> > routing information management for each of the registered carriers in
> > the world.
>
> The concept of "registered carriers" no longer exists in many countries. A
> list of carriers that are considered to be in that category is published
> at:
>
>   http://www.itu.int/en/ITU-T/inr/Pages/roa.aspx
>
> However, I'm not aware of any publicly available compilation of routing
> information for telephony. As far as I know, operators maintain their own
> proprietary routing tables.
>
> >(MODERN will enjoy more help than it has now.)
> >
> > For the first two, there will be a lot of commonalities, but there will
> > very likely be numerous requirements and challenges (and opportunities)
> > identified which should greatly benefit the development of the MODERN
> > problem statement(s).
> >
> > While this seems prudent to me, it might also be outside of the scope
> > of the IETF or any SDO to use this approach.  One of my job
> > responsibilities almost 30 years ago was database development for
> > routing translations and premise-based user-defined systems succeeded
> > where visionary approaches failed, so I am offering my view of long-ago
> > hard-won experience.
> >
> > Pierce
> >
> > -----Original Message-----
> > From: Modern [mailto:modern-bounces@ietf.org ] On Behalf
> Of Richard Hill
> > Sent: December 18, 2015 8:02 AM
> > To: 'DOLLY, MARTIN C' >
> > Cc: 'Steve Donovan' >; 'Adam
> Roach'
> > >; 'Alissa Cooper'  >;
> > modern@ietf.org ; 'Richard Shockey'  >; Gorman, Pierce
> > A [CTO] >; 'Brian Rosen' <
> br@brianrosen.net >
> > Subject: Re: [Modern] Problem statement draft as working group document
> >
> > NANP involves several countries other than the USA.  Should they be
> > encouraged to participate in the work?
> >
> > Best,
> > Richard
> >
> > > -----Original Message-----
> > > From: DOLLY, MARTIN C [mailto:md3135@att.com ]
> > > Sent: Friday, December 18, 2015 14:58
> > > To: Richard Hill
> > > Cc: Gorman, Pierce A [CTO]; Adam Roach; Steve Donovan; Brian Rosen;
> > > modern@ietf.org ; Alissa Cooper; Richard Shockey
> > > Subject: Re: [Modern] Problem statement draft as working group
> > > document
> > >
> > > I do not think this work impacts beyond NANP
> > >
> > > Martin C Dolly
> > > Lead Member of Technical Staff
> > > Core & Government/Regulatory Standards AT&T
> > > Cell: 609-903-3360
> > > Email: md3135@att.com 
> > >
> > > > On Dec 18, 2015, at 7:53 AM, Richard Hill  > wrote:
> > > >
> > > > To be clear, I'm not suggesting that this group pause its work or
> > > wait
> > > > for inputs from ITU-T. I'm suggesting that it inform ITU-T of where
> > > it
> > > > stands and continue its work. If ITU-T replies, then the group
> > could
> > > > take that input into account in due course.
> > > >
> > > > Best,
> > > > Richard
> > > >
> > > >> -----Original Message-----
> > > >> From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com
> ]
> > > >> Sent: Friday, December 18, 2015 13:50
> > > >> To: Adam Roach
> > > >> Cc: Richard Shockey; Brian Rosen; Steve Donovan; Richard Hill;
> > > >> modern@ietf.org ; Alissa Cooper
> > > >> Subject: Re: [Modern] Problem statement draft as working group
> > > >> document
> > > >>
> > > >> Beyond persevering regardless of input and feedback, were there
> > > other
> > > >> lessons learned in CODEC that could be applied in this working
> > > group?
> > > >>
> > > >> Rich Hill's suggestion that learning requirements through an ITU
> > > >> study group could be beneficial seems logical.
> > > >>
> > > >> I'm not suggesting this as a stall tactic.  I'm suggesting that
> > > >> MODERN is taking on a global challenge and could benefit from
> > > >> Rich's suggestion.  Are there good reasons to ignore it?
> > > >>
> > > >> Sent from my iPad
> > > >>
> > > >>>> On Dec 17, 2015, at 12:23 PM, Adam Roach  >
> > wrote:
> > > >>>>
> > > >>>> On 12/17/15 11:57, Richard Shockey wrote:
> > > >>>> RS> Which some of us dispute. I really really believe that E.164
> > > >> numbering allocation is not within the Expertise of the IETF.
> > > >>>
> > > >>> An incredibly congruent objection was raised by several parties
> > in
> > > >> the chartering of CODEC. The result of proceeding anyway was
> > > >> objectively and subjectively the best audio codec ever produced.
> > > >>>
> > > >>> /a
> > > >>>
> > > >>> _______________________________________________
> > > >>> Modern mailing list
> > > >>> Modern@ietf.org 
> > > >>> https://www.ietf.org/mailman/listinfo/modern
> > > >>
> > > >> ________________________________
> > > >> Switch to Sprint and save 50% on Verizon, AT&T or T-Mobile rates.
> > > >> Your savings are guaranteed until 2018! Available on most plans.
> > > >> Limited time offer. Exclusions and restrictions apply. See
> > > >> sprint.com/save50 for details.
> > > >>
> > > >> ________________________________
> > > >>
> > > >> This e-mail may contain Sprint proprietary information intended
> > for
> > > >> the sole use of the recipient(s). Any use by others is prohibited.
> > > If
> > > >> you are not the intended recipient, please contact the sender and
> > > >> delete all copies of the message.
> > > >
> > > >
> > > > _______________________________________________
> > > > Modern mailing list
> > > > Modern@ietf.org 
> > > > https://www.ietf.org/mailman/listinfo/modern
> >
> >
> > _______________________________________________
> > Modern mailing list
> > Modern@ietf.org 
> > https://www.ietf.org/mailman/listinfo/modern
> >
> > ________________________________
> > Switch to Sprint and save 50% on Verizon, AT&T or T-Mobile rates. Your
> > savings are guaranteed until 2018! Available on most plans. Limited
> > time offer. Exclusions and restrictions apply. See
> > sprint.com/save50 for details.
> >
> > ________________________________
> >
> > This e-mail may contain Sprint proprietary information intended for the
> > sole use of the recipient(s). Any use by others is prohibited. If you
> > are not the intended recipient, please contact the sender and delete
> > all copies of the message.
>
>
> _______________________________________________
> Modern mailing list
> Modern@ietf.org 
> https://www.ietf.org/mailman/listinfo/modern
>

--001a11c37c5403e3e205273ef40d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I hear consensus!=C2=A0Proposed alternative problem statement capturing the=
 mood:=C2=A0


WE DON'T KNOW WHAT WE DON'=
T KNOW (So let's find out how to find out)

1. We'd like to=C2=A0have Internet=C2=A0protocol support for=C2=A0man=
agement, allocation, assignment=C2=A0etc., of "telephone numbers"=
 worldwide=C2=A0("The Domain")

2. We kno=
w The Domain has existed for 100 years, and takes=C2=A0enormous number of s=
hapes in Real Networks, some regulatory, some commercial, some technical

3. We don't yet which of these are important eno=
ugh to bake into a protocol

4. If we make a protoc=
ol that's not a good=C2=A0fit for The Domain, we're making the prob=
lem worse=C2=A0because a bad protocol=C2=A0further obfuscates=C2=A0The Doma=
in and distracts=C2=A0from working protocols of the future

5. Thus the REAL PROBLEM TO BE SOLVED=C2=A0is how to=C2=A0understa=
nd enough of The=C2=A0Domain to have a reasonable chance of making=C2=A0a r=
elevant protocol, likely to be achieved by=C2=A0actively collecting informa=
tion from the parties involved in The Domain=C2=A0



---
Mark R=C2=A0Lindsey, mailto:lindsey@e-c-group.com, tel:+1-22=
9-316-0013, http://ecg.co/lindsey
=

On Saturday, December 19, 2015, Richard Hill <rhill@hill-a.ch> wrote:
Please see below.



Thanks and best,

Richard



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

> From: Gorman, Pierce A [CTO] [mailto:Pierce.G=
orman@sprint.com]

> Sent: Friday, December 18, 2015 23:57

> To: Richard Hill; 'DOLLY, MARTIN C'

> Cc: 'Steve Donovan'; 'Adam Roach'; 'Alissa Cooper&=
#39;; modern@ietf.org;

> 'Richard Shockey'; 'Brian Rosen'

> Subject: RE: [Modern] Problem statement draft as working group documen=
t

>

> You bring up something I wondered about.

>

> I'm new to how things proceed in standards development but was hop=
eful

> your comment about an ITU-T Study Group could provide some things I
> thought would be of special value to the work in MODERN.

>

> First, a dictionary or other compendium of all of the impacted

> regulatory numbering authority bodies



As others have pointed out, a numbering authority would only be impacted if=


it agreed to use the protocols developed in this group. Almost all of the
world's numbering authorities are represented in ITU-T. You can find th=
e

coordinates of the regulator by going to the individual country page from
the overall country listing at:





https://www.itu.int/online/mm/scrip=
ts/mm.list?_search=3DITUstates&_languageid=3D

1



A variety of information on international numbering resources (including
E.164 numbers and national numbering plans) is available at:



=C2=A0 http://www.itu.int/en/ITU-T/inr/Pages/default.aspx



ITU-D publishes a "regulatory tracker" that includes information =
such as

whether VoIP is allowed, see:



=C2=A0 http://www.itu.int/en/ITU-D/Regulatory-M=
arket/tracker/Pages/default.aspx



An overview of the regulatory policies in each country is published at:



=C2=A0 http://www.itu.int/net4/itu-d/icteye/CountryProfile.aspx=




However, I don't see anything specific there about number allocation
policies or regulations.



> and some high-level assessment

> and/or overview of their assignment and management processes would be<=
br>
> very helpful.



Maybe somebody has done an overall synthesis, but if so I'm not aware o=
f it.



The EU Framework Directive has an article on Numbering, Naming and

Addressing (Art. 10). Although it does not explicitly say so, to me it seem=
s

to imply that numbers can be assigned only to providers, not to end-users.<=
br>
The directive is at:





http://eur-lex.europa.eu/LexUriServ/LexUriServ.=
do?uri=3DOJ:L:2002:108:0033:005

0:EN:PDF



>

> Second, a similar comprehensive work identifying all of the variations=


> in types of numbers, any assignment-specific requirements (e.g., toll<=
br>
> free should be instructive) by country would be good.



You will find much of that in the ITU's compilation of national numberi=
ng

plans, at:



=C2=A0 http://www.itu.int/oth/T0202.aspx?parent=3DT0202



There is a specific page for emergency numbers, at:



=C2=A0http://www.itu.int/net/itu-t/inrdb/e129_important_n=
umbers.aspx



>

> Finally, a list of points of contact for number administration



You will find that in the listing of ITU members referenced above.



> and

> routing information management for each of the registered carriers in<=
br>
> the world.



The concept of "registered carriers" no longer exists in many cou=
ntries. A

list of carriers that are considered to be in that category is published at=
:



=C2=A0 http://www.itu.int/en/ITU-T/inr/Pages/roa.aspx



However, I'm not aware of any publicly available compilation of routing=


information for telephony. As far as I know, operators maintain their own
proprietary routing tables.



>(MODERN will enjoy more help than it has now.)

>

> For the first two, there will be a lot of commonalities, but there wil=
l

> very likely be numerous requirements and challenges (and opportunities=
)

> identified which should greatly benefit the development of the MODERN<=
br>
> problem statement(s).

>

> While this seems prudent to me, it might also be outside of the scope<=
br>
> of the IETF or any SDO to use this approach.=C2=A0 One of my job

> responsibilities almost 30 years ago was database development for

> routing translations and premise-based user-defined systems succeeded<=
br>
> where visionary approaches failed, so I am offering my view of long-ag=
o

> hard-won experience.

>

> Pierce

>

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

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

> Sent: December 18, 2015 8:02 AM

> To: 'DOLLY, MARTIN C' <md3135@att.com>=


> Cc: 'Steve Donovan' <srdonovan@usdo=
novans.com>; 'Adam Roach'

> <adam@nostrum.com>; 'Alissa Cooper' =
<alissa@cooperw.in>;

> modern@ietf.org; 'Richard Shockey' <richard@shockey.us>; Gorman, Pierce

> A [CTO] <Pierce.Gorman@sprint.com>; =
'Brian Rosen' <br@brianrosen.net>

> Subject: Re: [Modern] Problem statement draft as working group documen=
t

>

> NANP involves several countries other than the USA.=C2=A0 Should they =
be

> encouraged to participate in the work?

>

> Best,

> Richard

>

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

> > From: DOLLY, MARTIN C [mailto:md3135@att.com]
> > Sent: Friday, December 18, 2015 14:58

> > To: Richard Hill

> > Cc: Gorman, Pierce A [CTO]; Adam Roach; Steve Donovan; Brian Rose=
n;

> > modern@ietf.org; Alissa Cooper; Richard Shocke=
y

> > Subject: Re: [Modern] Problem statement draft as working group
> > document

> >

> > I do not think this work impacts beyond NANP

> >

> > Martin C Dolly

> > Lead Member of Technical Staff

> > Core & Government/Regulatory Standards AT&T

> > Cell: 609-903-3360

> > Email: md3135@att.com

> >

> > > On Dec 18, 2015, at 7:53 AM, Richard Hill <rhill@hill-a.ch> wrote:

> > >

> > > To be clear, I'm not suggesting that this group pause it=
s work or

> > wait

> > > for inputs from ITU-T. I'm suggesting that it inform ITU=
-T of where

> > it

> > > stands and continue its work. If ITU-T replies, then the gro=
up

> could

> > > take that input into account in due course.

> > >

> > > Best,

> > > Richard

> > >

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

> > >> From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com]

> > >> Sent: Friday, December 18, 2015 13:50

> > >> To: Adam Roach

> > >> Cc: Richard Shockey; Brian Rosen; Steve Donovan; Richard=
 Hill;

> > >> modern@ietf.org; Alissa Cooper

> > >> Subject: Re: [Modern] Problem statement draft as working=
 group

> > >> document

> > >>

> > >> Beyond persevering regardless of input and feedback, wer=
e there

> > other

> > >> lessons learned in CODEC that could be applied in this w=
orking

> > group?

> > >>

> > >> Rich Hill's suggestion that learning requirements th=
rough an ITU

> > >> study group could be beneficial seems logical.

> > >>

> > >> I'm not suggesting this as a stall tactic.=C2=A0 I&#=
39;m suggesting that

> > >> MODERN is taking on a global challenge and could benefit=
 from

> > >> Rich's suggestion.=C2=A0 Are there good reasons to i=
gnore it?

> > >>

> > >> Sent from my iPad

> > >>

> > >>>> On Dec 17, 2015, at 12:23 PM, Adam Roach <adam@nostrum.com>

> wrote:

> > >>>>

> > >>>> On 12/17/15 11:57, Richard Shockey wrote:

> > >>>> RS> Which some of us dispute. I really really=
 believe that E.164

> > >> numbering allocation is not within the Expertise of the =
IETF.

> > >>>

> > >>> An incredibly congruent objection was raised by seve=
ral parties

> in

> > >> the chartering of CODEC. The result of proceeding anyway=
 was

> > >> objectively and subjectively the best audio codec ever p=
roduced.

> > >>>

> > >>> /a

> > >>>

> > >>> _______________________________________________

> > >>> Modern mailing list

> > >>> Modern@ietf.org

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

> > >>

> > >> ________________________________

> > >> Switch to Sprint and save 50% on Verizon, AT&T or T-=
Mobile rates.

> > >> Your savings are guaranteed until 2018! Available on mos=
t plans.

> > >> Limited time offer. Exclusions and restrictions apply. S=
ee

> > >> s=
print.com/save50<http://sprint.com/50off> for details.

> > >>

> > >> ________________________________

> > >>

> > >> This e-mail may contain Sprint proprietary information i=
ntended

> for

> > >> the sole use of the recipient(s). Any use by others is p=
rohibited.

> > If

> > >> you are not the intended recipient, please contact the s=
ender 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

>

> ________________________________

> Switch to Sprint and save 50% on Verizon, AT&T or T-Mobile rates. =
Your

> savings are guaranteed until 2018! Available on most plans. Limited
> time offer. Exclusions and restrictions apply. See

> sprint.com/save=
50<http://spri=
nt.com/50off> for details.

>

> ________________________________

>

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

> sole use of the recipient(s). Any use by others is prohibited. If you<=
br>
> 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




--001a11c37c5403e3e205273ef40d--


From nobody Tue Dec 22 13:22: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 A72D11A905F for ; Tue, 22 Dec 2015 13:22:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level: 
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 p5di8TIzJ4cD for ; Tue, 22 Dec 2015 13:22:05 -0800 (PST)
Received: from smtp101.iad3a.emailsrvr.com (smtp101.iad3a.emailsrvr.com [173.203.187.101]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB231A905E for ; Tue, 22 Dec 2015 13:22:05 -0800 (PST)
Received: from smtp29.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp29.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 81CB0380184 for ; Tue, 22 Dec 2015 16:22:04 -0500 (EST)
X-Auth-ID: fluffy@iii.ca
Received: by smtp29.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 154723800AB for ; Tue, 22 Dec 2015 16:22:03 -0500 (EST)
X-Sender-Id: fluffy@iii.ca
Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.185]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Tue, 22 Dec 2015 16:22:04 -0500
From: Cullen Jennings 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <84ABB43B-7DCD-4AA3-A50C-E473796FF1AF@iii.ca>
Date: Tue, 22 Dec 2015 14:22:03 -0700
To: modern@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Subject: [Modern] phone numbers and geography
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 22 Dec 2015 21:22:06 -0000

Yes country codes are part of the delegation hierarchy in E.164 numbers. =
We all agree on that. On the details of what a given state inside the US =
does or does not do, it seems to me XKCD pretty much covered it with=20

https://xkcd.com/1129/

That is to say many of the things that caused the structure inside +1 to =
be relevant are becoming less relevant. But that said, I just don't see =
anything on the thread about this that changes what the modern-problems =
draft needs to say=20





From nobody Tue Dec 22 13:22: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 F0D041A9060 for ; Tue, 22 Dec 2015 13:22:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3drozKV5ENwO for ; Tue, 22 Dec 2015 13:22:06 -0800 (PST)
Received: from smtp101.iad3a.emailsrvr.com (smtp101.iad3a.emailsrvr.com [173.203.187.101]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0A7B1A905E for ; Tue, 22 Dec 2015 13:22:06 -0800 (PST)
Received: from smtp29.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp29.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 34D85380184; Tue, 22 Dec 2015 16:22:06 -0500 (EST)
X-Auth-ID: fluffy@iii.ca
Received: by smtp29.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id A746A3800AB;  Tue, 22 Dec 2015 16:22:05 -0500 (EST)
X-Sender-Id: fluffy@iii.ca
Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.185]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Tue, 22 Dec 2015 16:22:06 -0500
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Cullen Jennings 
In-Reply-To: <56465BCD.1090602@usdonovans.com>
Date: Tue, 22 Dec 2015 14:22:05 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <56465BCD.1090602@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "modern@ietf.org" 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 22 Dec 2015 21:22:08 -0000

I and a lot of other people provided input at IETF94 so I did not see =
any need to say more here.=20

However, there has been nothing new raised on the thread here that had =
not been brought prior to IETF94. I think it is very clear the list =
discussion has not changed the census from the meeting and thus I think =
this needs to be adopted now. What timeline do you have in mind for =
adopting this?

Thanks, Cullen


PS - yes the draft-peterson-modern-problems-02 draft looks more than =
fine for an WG -00 doc, in fact it looks close to ready for WGLC=20


> On Nov 13, 2015, at 2:53 PM, Steve Donovan  =
wrote:
>=20
> All,
>=20
> During the IETF94 MODERN WG meeting there was consensus that =
draft-peterson-modern-problems-02 be accepted as a working group =
document.  This would be to address the architecture Architecture =
Overview milestone.
>=20
> It was recognized that it is not in final form but would be a good =
starting point for the architecture overview.
>=20
> Please comment on whether or not this should become a working group =
document.
>=20
> Regards,
>=20
> Steve
>=20
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern


From nobody Tue Dec 22 20:54:47 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E3C1AC3EF for ; Tue, 22 Dec 2015 20:54:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.798
X-Spam-Level: 
X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 mcsAfC9jFHgG for ; Tue, 22 Dec 2015 20:54:38 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0112.outbound.protection.outlook.com [207.46.100.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACDC51A00B0 for ; Tue, 22 Dec 2015 20:54:38 -0800 (PST)
Received: from BY2FFO11FD037.protection.gbl (10.1.14.32) by BY2FFO11HUB015.protection.gbl (10.1.15.224) with Microsoft SMTP Server (TLS) id 15.1.355.15; Wed, 23 Dec 2015 04:54:36 +0000
Authentication-Results: spf=pass (sender IP is 144.230.172.36) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com;
Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.36 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.36; helo=plsapdm1.corp.sprint.com;
Received: from plsapdm1.corp.sprint.com (144.230.172.36) by BY2FFO11FD037.mail.protection.outlook.com (10.1.14.222) with Microsoft SMTP Server (TLS) id 15.1.355.15 via Frontend Transport; Wed, 23 Dec 2015 04:54:36 +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 tBN46Ida034718;  Tue, 22 Dec 2015 22:54:34 -0600
Received: from plswe13m07.ad.sprint.com (plswe13m07.corp.sprint.com [144.229.214.26]) by plsapdm1.corp.sprint.com with ESMTP id 1yw5rgm0ca-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 22 Dec 2015 22:54:34 -0600
Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 22 Dec 2015 22:54:33 -0600
Received: from PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed]) by PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed%24]) with mapi id 15.00.1076.000; Tue, 22 Dec 2015 22:54:33 -0600
From: "Gorman, Pierce A [CTO]" 
To: Cullen Jennings 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHRPP7UuJCb6QvyAkCw5tqT9QWjPJ7YAglh
Date: Wed, 23 Dec 2015 04:54:33 +0000
Message-ID: <3CE2889F-98E6-456D-A7CB-C7C1D0A14645@sprint.com>
References: <56465BCD.1090602@usdonovans.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
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD037; 1:dM2fSx+nEKAekZaoGIJfOL7172arRW+C/R+nHkkRnzAa1ho5cNK6qebrfBZD6vZ9yY8koRo/cAgrDLQR9z9yupRJJ8/T7Y3YkVzsuyh4h16O5jU9aF2HGB648r4+MRnt+Hvdfr6GQQsXON9+sJHxMcy0hHw8heo6rNfBTvkZ626r/sRxpr7hoAOo+M/2QCKZ/B1ZUPe4uJxwcQWrTlzymB30OUjewU0/98Ybl4nXlACfgdLa2YlzK+qhgx1LhhXnroCmqufyX8D1CgSwPSNuYBz8J2f2UxQ3LLPL3eas7D5Sn/QNUtoAhvLhDR9MMFTyqAfrjdIHE0ai5NTz3sF7hrDI7C7xRuHA5Rdi+LoeltDFOQanDxY6UxG+0E3VHFYQ
X-Forefront-Antispam-Report: CIP:144.230.172.36; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(24454002)(189002)(377454003)(164054003)(199003)(5003600100002)(33656002)(97756001)(11100500001)(76176999)(5003630100001)(1096002)(50986999)(54356999)(1220700001)(586003)(5008740100001)(5250100002)(15395725005)(6806005)(102836003)(5001960100002)(86362001)(2950100001)(46406003)(2900100001)(92566002)(19580395003)(15975445007)(23726003)(19580405001)(82746002)(110136002)(87936001)(81156007)(47776003)(36756003)(106466001)(97736004)(83716003)(106116001)(189998001)(50466002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB015; H:plsapdm1.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB015; 2:XL+ulXW7jDiU6YvNX2SyNHxi8T/yBiv4nSz9BPF/g1fL5SFq4FyYXIYor8LEBbuP1KMUn5s+OqH7BdFAUhVoXZq16CKsVBgrNymIwzP/G7brv8x502gaHmwmU05SB7t1qhCWa8TdyzayG4cTnfRVhA==; 3:8QpBvX492e3CemcrjsDycKw3PSNV4rpKzUAFV7LkqW3nTmDX+YlSR+wEG2lumPnaCReyXd5Ocp9oP62IXg1y0h2sEP1IKAEJ2YbxH5Pn5k1fa1R/WY8TM/FFz2Vm1GhkliFksRdlwfQ7D0jqe87c/7h1n5XyeAYJ9EU5YllsAKoBfZYyE5+OiDppSWR4N3UphSWz8AnOGUdiVptgFkrDJ1Q133wD6y6C/KlYjmIhrQot126s7XceMkUNtsDoZkYxyLqE4YTj7X8ux6xV32zmkA==; 25:YGsCWR6wIapGShTKqpJtCLOuW3JArl185oRGHCnRgsqA++TnVv+NryLyA9IvisPveh1amVpF4IblRf0VRWqdhRlhPsd4Sol/yEfRvZFGlz6+nAYJ5Z17QR5QXi+Zdpv3Yyu7UiC7LwRsUWlNPHT/0hg7/ACoxVlpNBAMSlxrZouQ8XsmgzrCdI4pChp3ZPtybmwZWym80WTIFznuOc3VPAqYU0gFLYe7A/HBktaGHmT4LZqw2sM1vEQqjqECjzxbcHoOoYFPvhEN1C8mykQofQ==
X-Exchange-Antispam-Report-Test: UriScan:; BCL:0; PCL:0; RULEID:(8251501002);  SRVR:BY2FFO11HUB015; UriScan:(18430343700868);
X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB015; 20:58V0MPDfG0FJU+NKS5Vlg1iu4aPVKFfUxrveM1uEZp289hdp8AA0ONG6ILR1XaH5Ch/0BrfEm+fCyHnDhfqc/p8em4sQJ6a+8vvOEk2OpXzCZftmqUU3RXwNk425udYPZ7EO054j1XwEZrpiywLWRvovtK3mJfooUerOrGKVRoeLSMxoL9d23Qso2vWe37u81Ti4jI1tiYIEG18Se6KLPeAoj0L5b9WzjwzdxqPfZhKEWS6idb02CGV3WVwtUNNw; 4:SYSroSBG9hGb2QhI2YkVGcb92lw2ac9OIqn5FwQFiIC+94yKA9SE0Whpz527jKPybK0h9HaPdRD74TfPJFc7H+U/mcR1yy5v03PXifFS3jlV0p88B8k9x50P+w+onMsmBOaIJV5tZ9LlOxLZgjCD5+1xFVyNNySDBZOhFcHWDLtmu/CU4o+c8o6r4yjh5YSrpET/xN8JVCcZhn0R3fTEIBUClww/6kz1mdqt1cvq3MHmd7Q0TBlK/Q4LlGq3yXnCxEivF0hG3RMraKaKrBDoWTT9I7EwTNr489/Ku6m90byCihoO+XusjoyX0jeGNqWih984Poi4npSWyiDj7VjxVN3TvwH5/85/cquUBYJjR0vCsn1RwOuaRe52ShY0S3KBQe2BDACbeq0jlV95J1jydWqbuJOrxliQnjTiY4VvZmHFNc6bWeai/jkBrhbxe/xd
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:BY2FFO11HUB015; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB015; 
X-Forefront-PRVS: 0799B1B2D7
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2FFO11HUB015; 23:ghj/SlfTurRVl461HdvhqAJgBFEMA1PX+bm46ysi?= =?us-ascii?Q?mg7dRByKcU8fq2SFPSypjzdzz3hsXZ/m+AgfOWrrgYNTgPk+w3arfJ/8i5Hr?= =?us-ascii?Q?nxLRe6gLhu2fynjGEe4kFl65LY3Bbk0T4ybv7SpFykoswP2Ny+PmKHgxTlJ7?= =?us-ascii?Q?SsmZVXAE5U/+4hV5u1aRZpJQrdfoLYjXpUTOspIi8YKqR/xiGtGOMAvzQ+kA?= =?us-ascii?Q?uvmutKjUkI317D68U2+NN4Z3441UOxo/WyRk1bPeXfqqucriEUGMiJxixaVD?= =?us-ascii?Q?D+zTY8Aq0CcQQ9IRq9YcVWe8Q01rWqYaLbtTvlO5MuEm4KbzJd7zkSH6pzUf?= =?us-ascii?Q?Go5drzfQQkM2Zko0LEJf5J8eDAO7YkSMbUBR/+s7zPjJAeMzx7L4htZOxnN2?= =?us-ascii?Q?YoKlJKMogjXVJ+Ro1Fcdl0zIOMsJrCwq1nHB0C1UQEtGylfAsQj1rIH4aKIS?= =?us-ascii?Q?6ldlw0vr+D8fl+2/3hM5DXuJd4QRVlSUDrMEReP7SbBW8y9qbjDD7YrTinWW?= =?us-ascii?Q?EsUSRZbEAHMIkghErBOOwVtIz1HVFxdpp5U2TvqxvwSqTBuVCIhySv6k5mjx?= =?us-ascii?Q?hlHcDHUmkQdKud1B0WXoN7lEdmpeVpbcs4DR1DduVe4Ts1jy55Ne9tJC166H?= =?us-ascii?Q?gHAuZsiNJ68OTUm4ybXxvDtFg37CO31OtDGAoGWjr8+qtEJVXp58/qcw2j2f?= =?us-ascii?Q?J0YFn/UGOXeXpIugm63znjV8e399mLmwuxCgKrUFWhjzhtjnj77HPf4eTgDU?= =?us-ascii?Q?+VYNfPACkH5Q9uVXrYVsSc36S9cyq7mZ0abNBP19vttFGqqX9IG/Jgm+6THn?= =?us-ascii?Q?+EPYiXeTBc0a6EMEyLoi7KGwRwQXz+Ko4c4EWHJBDIL0KWzV5hy5FLps7rVe?= =?us-ascii?Q?z1swGnmSN4jVg3VX9Q1AWESaa9YqHRsR8spocAGaVQamFKECupnqhsZ9lrOr?= =?us-ascii?Q?Qym//C2Rx4Nixb0NYT6od/eomWwMpgt2Yv2qEH1gx+FAN0/MfhL/p1+1EKeK?= =?us-ascii?Q?VTk9j/ZoS3aLoouhJkt79wikWA80y02rq450CBLTQluts9Pq2YWolW6XXyVe?= =?us-ascii?Q?A0BWqJu1G3wH6Z7XYFioMZGq/uzLkDL5KD4Hfg6+HMXKNlGiKn4NB4QCDuwV?= =?us-ascii?Q?7KF+jwuLQ3hTbMUnCjmM/1qIK0urpWQ01aIbXitO8WksGa0VEfRnt5vfnCrV?= =?us-ascii?Q?mY2HkAeBJ0GaeyW1WeyoxJf3nz++MDSN0QSs+s6piT1D4ro8qBtIqNWQT+yd?= =?us-ascii?Q?gjdhWALNozybS7QYAds=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB015; 5:Suk6aYG4dyiJ53xL+Kbwbdl3CKrpPz6Q/bk8ZISa7SrR9zd2owRDEGMpvFViXf+qsVFBniR2OesgF+snkzyqqgkt+Ymjx1Yu2V9sqQ9RrhvAd3wLb7LnMf6bXqZ47vFn6gd7SznMqevAMoq58h6qhg==; 24:jmNR943KrAwlF+dRVVNtVoThOEQ4ktIkNNP3pg9FFzonFL+urDvg+BJU6M3odLfPPX0fIyBnLqj4g7LloqMaZhaO6rwvpcRmevsIaPNMU04=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: sprint.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Dec 2015 04:54:36.5295 (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: BY2FFO11HUB015
Archived-At: 
Cc: Steve Donovan , "modern@ietf.org" 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 23 Dec 2015 04:54:46 -0000

Cullen,

What's your hurry?  Was there no useful discussion whatsoever since Novembe=
r?

Sent from my iPad

> On Dec 22, 2015, at 3:22 PM, Cullen Jennings  wrote:
>
>
> I and a lot of other people provided input at IETF94 so I did not see any=
 need to say more here.
>
> However, there has been nothing new raised on the thread here that had no=
t been brought prior to IETF94. I think it is very clear the list discussio=
n has not changed the census from the meeting and thus I think this needs t=
o be adopted now. What timeline do you have in mind for adopting this?
>
> Thanks, Cullen
>
>
> PS - yes the draft-peterson-modern-problems-02 draft looks more than fine=
 for an WG -00 doc, in fact it looks close to ready for WGLC
>
>
>> On Nov 13, 2015, at 2:53 PM, Steve Donovan  wr=
ote:
>>
>> All,
>>
>> During the IETF94 MODERN WG meeting there was consensus that draft-peter=
son-modern-problems-02 be accepted as a working group document.  This would=
 be to address the architecture Architecture Overview milestone.
>>
>> It was recognized that it is not in final form but would be a good start=
ing point for the architecture overview.
>>
>> Please comment on whether or not this should become a working group docu=
ment.
>>
>> Regards,
>>
>> Steve
>>
>> _______________________________________________
>> Modern mailing list
>> Modern@ietf.org
>> https://www.ietf.org/mailman/listinfo/modern
>
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern

________________________________
Switch to Sprint and save 50% on Verizon, AT&T or T-Mobile rates. Your savi=
ngs are guaranteed until 2018! Available on most plans. Limited time offer.=
 Exclusions and restrictions apply. See sprint.com/save50 for details.

________________________________

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


From nobody Mon Dec 28 14:54:17 2015
Return-Path: 
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55CFE1ACD98 for ; Mon, 28 Dec 2015 14:54:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.798
X-Spam-Level: 
X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 SHRXjUqpur6Y for ; Mon, 28 Dec 2015 14:54:12 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0719.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::719]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEF4C1ACD95 for ; Mon, 28 Dec 2015 14:54:11 -0800 (PST)
Received: from BL2FFO11FD054.protection.gbl (10.173.160.34) by BL2FFO11HUB027.protection.gbl (10.173.161.51) with Microsoft SMTP Server (TLS) id 15.1.355.15; Mon, 28 Dec 2015 22:53:52 +0000
Authentication-Results: spf=pass (sender IP is 144.230.172.36) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com;
Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.36 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.36; helo=plsapdm1.corp.sprint.com;
Received: from plsapdm1.corp.sprint.com (144.230.172.36) by BL2FFO11FD054.mail.protection.outlook.com (10.173.161.182) with Microsoft SMTP Server (TLS) id 15.1.355.15 via Frontend Transport; Mon, 28 Dec 2015 22:53:51 +0000
Received: from pps.filterd (plsapdm1.corp.sprint.com [127.0.0.1]) by plsapdm1.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id tBSJWAPc041458;  Mon, 28 Dec 2015 16:53:50 -0600
Received: from plswe13m07.ad.sprint.com (plswe13m07.corp.sprint.com [144.229.214.26]) by plsapdm1.corp.sprint.com with ESMTP id 201sdfyxpv-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 28 Dec 2015 16:53:50 -0600
Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 28 Dec 2015 16:53:50 -0600
Received: from PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed]) by PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed%24]) with mapi id 15.00.1076.000; Mon, 28 Dec 2015 16:53:50 -0600
From: "Gorman, Pierce A [CTO]" 
To: Steve Donovan 
Thread-Topic: [Modern] Problem statement draft problems
Thread-Index: AdFBwp0hgDf7SLKbRHCThGHvGReaug==
Date: Mon, 28 Dec 2015 22:53:49 +0000
Message-ID: <7ac7d9c9ccff477e8d8a5fcb91c9ef33@PLSWE13M08.ad.sprint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.214.116.24]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD054; 1:OhxAUHOYsqJnQt7ucX2SocVz7OzUQQST/1aZgyURtGnDwCpnuZuaZPu8pfe1arjoOuzffAEfn4SPUJZ+p3tklq4+oD1k4edLcrVlVNh1QILEkW1IVOS7CFI+/QZ4OcwPzRFUNkyZNVax6L5Ml2EFJ4vmnmy/kv4rAcbFnlj3p0nMfwp6PjmIBSyxfl62AbK0krVWkBs80Tuzgufouwx9UwkzjTAtiE6UoCUTnGGs8wCK7mM14lZWlouwgZKEFn1dk+tLqpKzdKf4Y2vOVfz3yz84L275AsGsTBGpgQuXaRR0DHLhLtengRwrsyfHL4wqqikoM5LNWfTyP2vLvoiiriv7QRlK0LKQ6eNxiycdplEwtLPht1uSkBHvud2jf86M
X-Forefront-Antispam-Report: CIP:144.230.172.36; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(189002)(199003)(51444003)(50466002)(5004730100002)(50986999)(46406003)(87936001)(19580395003)(5008740100001)(5003600100002)(15395725005)(97756001)(54356999)(23726003)(33646002)(92566002)(3846002)(86362001)(102836003)(81156007)(11100500001)(586003)(6806005)(47776003)(2900100001)(6116002)(15975445007)(97736004)(24736003)(108616004)(106466001)(1220700001)(189998001)(5250100002)(5001960100002)(1096002)(110136002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB027; H:plsapdm1.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB027; 2:aBwjbDdigDCMwUUUMZZt4vQECrAAxVteWQxoRUs6xCJGCTiPdTBv6R1D2OQgHWVCNqpwyvoH7hxdf5ZKHY22qxasLXneQE76GFRs9d4xacPxURTAi3AulwShGPFwnof7HSRhzbeSty2uUaTYGYUf9g==; 3:7ff3EPMG4EH5g6dEIdKxo5g2G+5MSjcPYUiDyCjZoN6CfH2uazZp71ttDZ5qQcNExoufP0vE+6/3kfZ1q+6FqlqwYY/lB91hhyGxZmjURWa9isfxvu77kq8eyJupl8NY54xtpnayzFQ9/ScI34p+gfXFvM2lXB7NXqtIDITSeQ5WIbNCt2QJowg1/2q+d0vJuijC2UmRspFmDcpnePvQ50tGAC695rozkUr6MxBAUJcDGQOcLzJqkgX6Aipjln8yJ4YE5GFmrnmrIpUqYqFtjQ==; 25:XFLrZD+mWSUg5U2sIPIIrg3t7dPjrQya9HwtwUm3JdLDoZkveTFf6cDJ/fjaeNa7NrWo+d8dwEOJ+DiPy/waOI+4KXc2F05bTlueWKYePLIMsKuc9Af89LVeBwcom0ghBGub0JiKkC/OKZnSESfbbAxqo/vOgN+v3Vi5AAO1ur8r83bw3o8KULii7QnthXz8VtnmeeobGGnJPF6Yvj5JZzk6xw6kF0nv4dL0I+IcGyumQTwP2YpUNsC1os407DraxLA4f/4As5NqpUpiNopwvw==
X-Exchange-Antispam-Report-Test: UriScan:; BCL:0; PCL:0; RULEID:(8251501002);  SRVR:BL2FFO11HUB027; UriScan:(18430343700868);
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB027; 20:mRquf7h5XC+m9rXm9t3FLR5Vh0jQHzf2AZ8FgXl4dM0n2zHGYdo/XsjFDy/mvYX/CR31W5ZLsp1Rhj2DDpnKbjw3NvreAO3MQe/BzKuRLPOWP5hydsE53Yadk2otpCpW3O0OZHjazxo1EDbCGHpej/yOH4LxnWbfi1yNhB21ac6c59Y24gjqEVEP+XyCmLJWEZouWV48qgOV6fKW/6S59kBydDyTllQCcN836aR2npYTuFDRrebvK8v1LUyBV0GN; 4:R/N2Qj8AWcLAvWJxSjbLUzjbMy0xSpEIm+CRwN2ECT1EJG8UrY12tXbNLa5/SfHvdftMKSlVrgbikmPN5wa8n4RHsiloIlIKsAh1u6h2/tnfVOxp5bBpLrmcgecZjoiyLDMPSn/sGYd9oPZgmzAQmp8oioFSm4CecprlU2qVe2RbK5M/rOKkwZgnNxC+tR1bECESfr7MabXdnupHN6P31PEcKczaG+SmV+Ck5xjBVRFuQOhQJodmqI/6YoFl9nnTuAkcgRiGHPSbjWA4bAQYFsaCGK3fm+ESzeHHCDzbrM6BZ07ohkKeYh3G1zihJMulsBwm5sjDbfINE3T0ZK1XC0ORgWF7lEAkOgyEg11LBH5tUurTqeCF7/gdmyfLL/5fbjXVbdOoTp/VI19bZba9LwaztmH1jORucXMBh2QJuBxtkY1RTi8s7BBzlK8nuDYb
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046); SRVR:BL2FFO11HUB027; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB027; 
X-Forefront-PRVS: 08041D247D
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2FFO11HUB027; 23:ek8jplLNRrWja/d2Zt2wYlJ3QJ97HgX2qmc9H5qP?= =?us-ascii?Q?2KRCpYF6gcnRfOhvbLIn6iEFCIpmSqQyqPnNedGidb/Bh93vz+Zd+bxVhPsW?= =?us-ascii?Q?AXIrWkKCM6joj13O1doo/DBV8zYJ1WIBD6PLdF2m0SIX/B4v8egwRgYuZtGs?= =?us-ascii?Q?iRSQr+p6joVwCFPa4FkJo0CxApFekQR3YerkWholvhSK5UJvCDNGxj+xz6Xb?= =?us-ascii?Q?uNxlMSge1ra1xLM5D4STBKkeFwcjeMAOchDkejpkS+EhDSDiDRYRxq1XB3of?= =?us-ascii?Q?y2Hb+8Rv+pO7seY28nH7MByxLRAsBAE0hvj9XBl/0pxdLISUyf5sPgH6e4iB?= =?us-ascii?Q?a+a3eBwAvSB9AebG2l0/vo/Omuc8MCtyzLQMxKYVJA88/0CZHHTuR5BlDYAn?= =?us-ascii?Q?TMV6KjiUIUaPgzByMbfTFIs/Y0iV+QYk1c6+ekY0oMp6NOlkgmDrIdqO4G5B?= =?us-ascii?Q?02hP8W9YmBN/ueYL4J+IHTrZqnMf7qfglVcM2skWBLiJkeL6NtERS6a+qJXx?= =?us-ascii?Q?zwN9dJqZVmGrGT+utTvcRwH8YjAtA/fZzR3OY9fpSgPFX9fvx1gedcNl52ol?= =?us-ascii?Q?gdcjZ4jlVpLYTjuN0CNf8bI4kIZXX8NFwgq5h4gru3rl7T2HQnQ5AhB/cNKU?= =?us-ascii?Q?klsdsiU86qyjyNG/ZEdovSdigwUUpLhq3kMAgg3IqMFXLtKaMexv5Nkbp7Nu?= =?us-ascii?Q?xXfb9E5k6xDyPwTmixvWcWTzEdHHBsRhFsUSt39HEzK2Y6RwyNELAiDEIHx9?= =?us-ascii?Q?bVfvk4NuKbGeOB7vwhvAImUi1FWW8lxQ+ZbcW01MlPrv6nJxSTAz3MUTSvoM?= =?us-ascii?Q?GwVRRU28B7o9sMQhknw3bscg2elSFmVw7gdy6LxzPggIs37NEty+6SS4MtDH?= =?us-ascii?Q?lSe5932kw4aCRrQ4yRx5GN/85kNNxIK2kG4jdkNK+/G+SmukSZyMg7594zMe?= =?us-ascii?Q?a7kbShr/9baSZsy4PBhsIYHjgj4i0E6wqNN2ihbB5v+ZmbVkrKR34GNcXcZ0?= =?us-ascii?Q?2AMgQtvNXp28Gze4yay8UrU9xdxVR2Dw5pSYuSp1PNw5xVMg3ldxLGzk+LaD?= =?us-ascii?Q?m15GghBUB9EDO7NqsZjezsbdVWA/8y2crZ5YR2YILPljw2/ERg=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB027; 5:Sl8z1RYjMxotUGx1sNkikXoozAEqM5xBSSFWLk6VCVECC6ptDQUQgvKUNZBrLJCPhcKiOURRxGu7cZ81GXniQjkR7zTABGKaNzRbWZANJmhBUisRPEhYSR+TxdRdXM0Lp8zrv/e1E980+m17RFXOGQ==; 24:hymS8EjL56cNrunkPDAiH69fHWlFBm1YthCbqKOfb01sZZPl5H7qsJErBqaPGDGv6SZY52Qcfhw0YuG9W7s2IzsH2P0qJTo6/mlsVLcs52E=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: sprint.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Dec 2015 22:53:51.2431 (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: BL2FFO11HUB027
Archived-At: 
Cc: "modern@ietf.org" 
Subject: Re: [Modern] Problem statement draft problems
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Dec 2015 22:54:15 -0000

Steve,

In section 1 I would strike the sentence, "   Telephone numbering, however,=
 has long been transitioning away from a provider-centric model towards a u=
ser-centric model."  I think the statement is arguable and isn't needed.

The statement, " TN administration processes rooted in PSTN technology and =
policies dictate that this be an exception process fraught with problems an=
d delays" may stand on it's own for someone familiar with the technology, p=
olicies, problems, and delays, but I think that is probably a small minorit=
y.

Can you elaborate?  If not, I suggest removing this statement as well.

Also, I would suggest that users already have full control of their TN.  Ce=
rtainly nobody will take it from them (although the area code portion of te=
lephone numbers using the NANP dial plan can and does occassionally change)=
.  And the porting process is solely driven by the users.  (Although it mig=
ht be worth pointing out porting in order to improve inbound call routing t=
o IMS-based numbers has been a consideration for some North American carrie=
rs deploying VoLTE.)

The statement, " Ideally the user would have full control of their TN and w=
ould drive the porting process on their own rather than rely on complex and=
 time
consuming back office processes among multiple service providers" needs wor=
k.  What is the definition of "full control" and what makes full control "i=
deal"?

How about, "Some members of the MODERN working group think users ought to b=
e able to use an Internet-available database to directly make changes to th=
e services associated with and the provisioning of their telephone number w=
ithout assistance from service providera."?

As mentioned before, claiming that the back office process among multiple s=
ervice providers is complex does not imply harm or even a problem to be fix=
ed.  Telephony is complex, but it is also very useful so the fact that it i=
s complex doesn't mean that it is bad, harmful, or a problem to be addresse=
d.

I recommend striking the phrase, "rather than rely on complex and time cons=
uming back office processes among multiple service providers".

Part of the problem here is you cannot really assert a priori that a MODERN=
 system will be less time consuming or even less complex.  The fact that th=
e user will necessarily require assistance from one or more service provide=
rs in completing the provisioning of their service (in the case of mobile t=
elephony at least) makes this a certainty.  In fact, it would be easy to ar=
gue that MODERN will be more complex.

I'm also confused by the reference to back office processes as though they =
are inherently harmful.  Other terms for the same activity are Operational =
Support Systems (OSS) and Business Support Systems (BSS).  These terms don'=
t have a negative or positive connotation though, so perhaps they also don'=
t belong in a problem statement?

With respect to geographic number assignment, the rejoinder, "But the overw=
helming success of mobile telephones has increasing eroded the connection b=
etween numbers and regions" has problems at least in the context of the Nor=
th American numbering plan.

I think what you mean is that after a mobile telephone number is assigned (=
likely for the majority of a user's life once non-geographic portability is=
 supported), a fair quantity of users (but far less than even 50%?) will mo=
ve outside of the geography of the original assignment rendering the geogra=
phic information associated with that mobile number anachronistic and inacc=
urate.  I would agree with this, and I would agree it causes problems for s=
ervice providers.  I wouldn't necessarily agree it's a problem a new MODERN=
 system could help with.

What is lost in this view is that there is an underlying routing number whi=
ch still retains a very certain geographic component.  Even if we eliminate=
d routing numbers and their reference to the LERG (again North America-cent=
ric view), there are very real operational reasons for wanting to recognize=
 geography when "homing" the terminating service processing (at least).

One of the problems with Internet telephony is the lack of recognition for =
geography both in telephone call routing and in number assignment.  Underst=
anding geography and it's interaction with call processing and numbering is=
 going to be one of the key challenges for MODERN.  I don't mean this as a =
reason not to work on MODERN. I mean it as helpful hint.  There is a real c=
ost both to service providers and users for unoptimized call routing and me=
dia transport.

I recommend changing the statement to, " But the overwhelming success of mo=
bile telephones has increasing obfuscated the connection between numbers an=
d regions".

This way you point out that there is and should be an intentional relations=
hip between mobile telephone numbering and operations at least, but that po=
rtability and Internet-telephony present special signaling and media path o=
ptimization problems.

The issue will be for MODERN WG how to develop a new system of telephone nu=
mber databasing that doesn't just recognize those problems, but somehow hel=
ps with them beyond what is available with conventional mechanisms.

That's more than enough for this session.  I'll try to pick up tomorrow.

Regards,

Pierce


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

________________________________

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


From nobody Tue Dec 29 15:29:50 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 34D321A8ACC for ; Tue, 29 Dec 2015 15:29:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level: 
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  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 Dv9KRjA-k8cV for ; Tue, 29 Dec 2015 15:29:46 -0800 (PST)
Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id DCE691A8ACB for ; Tue, 29 Dec 2015 15:29:45 -0800 (PST)
Received: (qmail 14526 invoked by uid 0); 29 Dec 2015 23:29:45 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy1.mail.unifiedlayer.com with SMTP; 29 Dec 2015 23:29:45 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with  id zi9a1r00H1MNPNq01i9dZn; Tue, 29 Dec 2015 23:09:43 -0700
X-Authority-Analysis: v=2.1 cv=bej4Do/B c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=wUQvQvOEmiQA:10 a=jqBRFv0mrdUA:10 a=FMnjzkzcAAAA:8 a=48vgC7mUAAAA:8 a=gxZvrgisAAAA:8 a=kKYZitD_28K1mjMe4VsA:9 a=N9tCvSuQj4uei8y3:21 a=XqU_Fe1vir23xX83:21 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us;  s=default;  h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=C1cUXQEG7FFIZMwsOYyPG8aB08cv0OqMhTPo76jyrDk=;  b=QDqlu5COkRJv2TXZt4BtUDXluHLLvy7atm2FltiHqrqvSkKu4zMhaePxvJEq+NpnXjv03czaqAcrPieurlnY+tJU3zJW+wLSHfhfRahrNqFGR9rpUGDAzcXRTrQ/MZar;
Received: from [100.36.26.202] (port=58673 helo=[192.168.1.9]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aE3Oa-0006YK-HV; Tue, 29 Dec 2015 16:09:36 -0700
User-Agent: Microsoft-MacOutlook/0.0.0.151217
Date: Tue, 29 Dec 2015 18:09:29 -0500
From: Richard Shockey 
To: "DRAGE, Keith (Keith)" , Mark Delany , "modern@ietf.org" 
Message-ID: <4BCC5D71-1D49-432D-B796-CC57E229C517@shockey.us>
Thread-Topic: [Modern] Problem statement draft as working group document
References:     <0F8F091A-7255-4781-81A3-48400BC670A1@att.com>  <1BD85DAA-9DC4-459F-91E1-A9ACD51F7CEC@att.com> <20151218014249.41761.qmail@f5-external.bushwire.net> <949EF20990823C4C85C18D59AA11AD8BADE25DCC@FR712WXCHMBA11.zeu.alcatel-lucent.com>
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADE25DCC@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us}
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 29 Dec 2015 23:29:48 -0000

Keith you are correct it does not .. Some of this might be useful some of i=
t may not.  Certainly our experience with ENUM tells us to be cautious about=
 playing around with matters under NRA authority.=20

VOIP transition is already in place in multiple jurisdictions.  It is a mat=
ter of national policy in the US UK Canada etc.  The All IP transition is a =
matter of strategic concern to every supplier serving the industry. The carr=
iers have made the decision. Its not just US Carriers this is DTAG as well. =
 You know this.

http://www.lightreading.com/nfv/nfv-strategies/dts-journey-to-a-new-ip-worl=
d/v/d-id/720033?

There is some concern about the underlying databases. Particularly those in=
volving LNP.  I have no objection to offering tools to SP=E2=80=99s but target the=
 application that makes sense. Interconnection metadata.  What do we do with=
 carrier CERTS in STIR.  Something that is practial deployable. Not this num=
bering administration BS.=20






On 12/18/15, 5:45 AM, "Modern on behalf of DRAGE, Keith (Keith)"  wrote:

>I am not aware that VOIP transition is requires the MODERN work as a preco=
ndition.
>
>It is just a tool that some people think might be used (and that is potent=
ially independent of VOIP usage).
>
>Regards
>
>Keith
>
>-----Original Message-----
>From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Mark Delany
>Sent: 18 December 2015 01:43
>To: modern@ietf.org
>Subject: Re: [Modern] Problem statement draft as working group document
>
>The Australian environment for one is likely to have growing interest give=
n the forced migration of practically all PSTN to VOIP as a consequence of t=
heir National Broadband Network (NBN).
>
>I don't know of the NZ experience first-hand, but given they are making a =
similar transition many of the same issues will arise there.
>
>Maybe not today, but given the life-cycle of the IETF processes, it's enti=
rely reasonable to think that WG product should keep these regional trends i=
n mind.
>
>
>Mark.
>
>_______________________________________________
>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 Dec 30 07:21: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 3E94D1ACD4D for ; Wed, 30 Dec 2015 07:21:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.579
X-Spam-Level: *
X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60nJHATt3nI7 for ; Wed, 30 Dec 2015 07:21:29 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2EAE1ACD47 for ; Wed, 30 Dec 2015 07:21:29 -0800 (PST)
Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:56804 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1aEIZ5-003pOa-VQ for modern@ietf.org; Wed, 30 Dec 2015 07:21:29 -0800
To: modern@ietf.org
References: <56465BCD.1090602@usdonovans.com>  <3CE2889F-98E6-456D-A7CB-C7C1D0A14645@sprint.com>
From: Steve Donovan 
Message-ID: <5683F677.4080409@usdonovans.com>
Date: Wed, 30 Dec 2015 09:21:27 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <3CE2889F-98E6-456D-A7CB-C7C1D0A14645@sprint.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 30 Dec 2015 15:21:31 -0000

Pierce,

There is no hurry or reason to delay in advancing a draft to becoming a 
working group draft.  Doing so does not say that the contents of the 
draft are finished.  Rather it says that the draft is a good starting 
point for addressing a working group milestone. Despite Cullen's opinion 
that the document is close to ready for WGLC, that is not what we are 
discussing at this point.  The hurdle for a document being ready for 
WGLC is much higher than it becoming a working group document.  In fact, 
not all drafts that become working group documents make it to WGLC, much 
less RFC status.

We had consensus in the working group meeting at IETF 94.  So far I 
haven't seen arguments saying that the document isn't suitable to become 
a working group document.  There is good discussion on the content of 
the draft, but that discussion can continue independent of the status of 
the draft.

I will wait until after the holiday's to renew this discussion but it 
appears to me that we can make the document a working group item.

Regards,

Steve

On 12/22/15 10:54 PM, Gorman, Pierce A [CTO] wrote:
> Cullen,
>
> What's your hurry?  Was there no useful discussion whatsoever since November?
>
> Sent from my iPad
>
>> On Dec 22, 2015, at 3:22 PM, Cullen Jennings  wrote:
>>
>>
>> I and a lot of other people provided input at IETF94 so I did not see any need to say more here.
>>
>> However, there has been nothing new raised on the thread here that had not been brought prior to IETF94. I think it is very clear the list discussion has not changed the census from the meeting and thus I think this needs to be adopted now. What timeline do you have in mind for adopting this?
>>
>> Thanks, Cullen
>>
>>
>> PS - yes the draft-peterson-modern-problems-02 draft looks more than fine for an WG -00 doc, in fact it looks close to ready for WGLC
>>
>>
>>> On Nov 13, 2015, at 2:53 PM, Steve Donovan  wrote:
>>>
>>> All,
>>>
>>> During the IETF94 MODERN WG meeting there was consensus that draft-peterson-modern-problems-02 be accepted as a working group document.  This would be to address the architecture Architecture Overview milestone.
>>>
>>> It was recognized that it is not in final form but would be a good starting point for the architecture overview.
>>>
>>> Please comment on whether or not this should become a working group document.
>>>
>>> Regards,
>>>
>>> Steve
>>>
>>> _______________________________________________
>>> Modern mailing list
>>> Modern@ietf.org
>>> https://www.ietf.org/mailman/listinfo/modern
>> _______________________________________________
>> Modern mailing list
>> Modern@ietf.org
>> https://www.ietf.org/mailman/listinfo/modern
> ________________________________
> Switch to Sprint and save 50% on Verizon, AT&T or T-Mobile rates. Your savings are guaranteed until 2018! Available on most plans. Limited time offer. Exclusions and restrictions apply. See sprint.com/save50 for details.
>
> ________________________________
>
> This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
>
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern


From nobody Wed Dec 30 07:24: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 650051ACD41 for ; Wed, 30 Dec 2015 07:24:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k-tdt6knvoP for ; Wed, 30 Dec 2015 07:24:21 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 477CF1A8AF9 for ; Wed, 30 Dec 2015 07:24:21 -0800 (PST)
Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:56878 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1aEIbr-003qtG-In for modern@ietf.org; Wed, 30 Dec 2015 07:24:21 -0800
To: modern@ietf.org
References:     <0F8F091A-7255-4781-81A3-48400BC670A1@att.com>  <1BD85DAA-9DC4-459F-91E1-A9ACD51F7CEC@att.com> <20151218014249.41761.qmail@f5-external.bushwire.net> <949EF20990823C4C85C18D59AA11AD8BADE25DCC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <4BCC5D71-1D49-432D-B796-CC57E229C517@shockey.us>
From: Steve Donovan 
Message-ID: <5683F723.7050208@usdonovans.com>
Date: Wed, 30 Dec 2015 09:24:19 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <4BCC5D71-1D49-432D-B796-CC57E229C517@shockey.us>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 30 Dec 2015 15:24:22 -0000

Richard,

We have a working group formed to address what you refer to as 
"numbering administration BS".  This is what the working group will be 
working on.  If there is additional work needed around interconnection 
metadata or other tools for handling other types of data then you are 
free to propose a new working group.

Regards,

Steve

On 12/29/15 5:09 PM, Richard Shockey wrote:
> Keith you are correct it does not .. Some of this might be useful some of it may not.  Certainly our experience with ENUM tells us to be cautious about playing around with matters under NRA authority.
>
> VOIP transition is already in place in multiple jurisdictions.  It is a matter of national policy in the US UK Canada etc.  The All IP transition is a matter of strategic concern to every supplier serving the industry. The carriers have made the decision. Its not just US Carriers this is DTAG as well.  You know this.
>
> http://www.lightreading.com/nfv/nfv-strategies/dts-journey-to-a-new-ip-world/v/d-id/720033?
>
> There is some concern about the underlying databases. Particularly those involving LNP.  I have no objection to offering tools to SP’s but target the application that makes sense. Interconnection metadata.  What do we do with carrier CERTS in STIR.  Something that is practial deployable. Not this numbering administration BS.
>
>
>
>
>
>
> On 12/18/15, 5:45 AM, "Modern on behalf of DRAGE, Keith (Keith)"  wrote:
>
>> I am not aware that VOIP transition is requires the MODERN work as a precondition.
>>
>> It is just a tool that some people think might be used (and that is potentially independent of VOIP usage).
>>
>> Regards
>>
>> Keith
>>
>> -----Original Message-----
>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Mark Delany
>> Sent: 18 December 2015 01:43
>> To: modern@ietf.org
>> Subject: Re: [Modern] Problem statement draft as working group document
>>
>> The Australian environment for one is likely to have growing interest given the forced migration of practically all PSTN to VOIP as a consequence of their National Broadband Network (NBN).
>>
>> I don't know of the NZ experience first-hand, but given they are making a similar transition many of the same issues will arise there.
>>
>> Maybe not today, but given the life-cycle of the IETF processes, it's entirely reasonable to think that WG product should keep these regional trends in mind.
>>
>>
>> Mark.
>>
>> _______________________________________________
>> 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 Dec 30 07:33: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 6C3AE1ACD46 for ; Wed, 30 Dec 2015 07:33:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.798
X-Spam-Level: 
X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 JYHM-KOSeq2O for ; Wed, 30 Dec 2015 07:33:48 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0120.outbound.protection.outlook.com [207.46.100.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E932F1A8AF4 for ; Wed, 30 Dec 2015 07:33:47 -0800 (PST)
Received: from BY2FFO11FD047.protection.gbl (10.1.14.30) by BY2FFO11HUB007.protection.gbl (10.1.14.213) with Microsoft SMTP Server (TLS) id 15.1.355.15; Wed, 30 Dec 2015 15:33:46 +0000
Authentication-Results: spf=pass (sender IP is 144.230.32.82) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com;
Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.32.82 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.82; helo=preapdm3.corp.sprint.com;
Received: from preapdm3.corp.sprint.com (144.230.32.82) by BY2FFO11FD047.mail.protection.outlook.com (10.1.15.175) with Microsoft SMTP Server (TLS) id 15.1.355.15 via Frontend Transport; Wed, 30 Dec 2015 15:33:46 +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 tBUFJTHZ037849;  Wed, 30 Dec 2015 10:33:45 -0500
Received: from plswe13m07.ad.sprint.com (plswe13m07.corp.sprint.com [144.229.214.26]) by preapdm3.corp.sprint.com with ESMTP id 201p17mx92-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 30 Dec 2015 10:33:45 -0500
Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 30 Dec 2015 09:33:43 -0600
Received: from PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed]) by PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed%24]) with mapi id 15.00.1076.000; Wed, 30 Dec 2015 09:33:43 -0600
From: "Gorman, Pierce A [CTO]" 
To: Steve Donovan , "modern@ietf.org" 
Thread-Topic: [Modern] Problem statement draft as working group document
Thread-Index: AQHRPP7UuJCb6QvyAkCw5tqT9QWjPJ7YAglhgAwUD4D//5u4gA==
Date: Wed, 30 Dec 2015 15:33:43 +0000
Message-ID: <0ecc832d180d4466a333fb12f3e3d766@PLSWE13M08.ad.sprint.com>
References: <56465BCD.1090602@usdonovans.com>  <3CE2889F-98E6-456D-A7CB-C7C1D0A14645@sprint.com> <5683F677.4080409@usdonovans.com>
In-Reply-To: <5683F677.4080409@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.214.116.39]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD047; 1:tYeArnI5YtyOZ0i6ZEcfBPS4pfAgvjikn5RWlrdBK664znz76VDoVdMPoBBujFXk2pfcF06Uc0NhUwrIkQv3hKNbMGW4rdQDfyv9O3pMpLsYgkAyrIJEZ4HPbyBMq+zpCTGm8TEeRvQMlB07hjIVbdB+LpsGI//h3HjKlyupId/WN6ZjyMWZYI/c/Cg8sX5jJ4KAh4WtmT9AQQqnVY5GEQlzcpoY5q9FU6fA5qJjb2IFV4WoVF4zxzdcBD/uZN7vwVdKT5zJlvrALsEtK+g62E30lp53QlnPCgPSO6Ns78Nk/DTUIcTE8ON4QUMuvu8I/fsJc3xtHykVg75DbLtVJ9UAuy4TJPLz9sWnOW+P7Cqiv38XRFvg2UALj066bfWR
X-Forefront-Antispam-Report: CIP:144.230.32.82; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(24454002)(377454003)(164054003)(13464003)(199003)(189002)(479174004)(54356999)(19580395003)(6116002)(76176999)(86362001)(108616004)(93886004)(47776003)(15975445007)(5003630100001)(50986999)(106116001)(24736003)(106466001)(2900100001)(33646002)(15395725005)(2950100001)(5001770100001)(5250100002)(2501003)(97736004)(5001960100002)(102836003)(19580405001)(97756001)(189998001)(50466002)(87936001)(5004730100002)(5003600100002)(1220700001)(1096002)(92566002)(81156007)(46406003)(23726003)(11100500001)(586003)(3846002)(107886002)(5008740100001)(6806005); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB007; H:preapdm3.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB007; 2:YoNOtxbR9/VxlHWlhHEOJRrhaaW0J8dNciFuIcInsHgjfGzaeTj14Ju0FrZRsMqeKzCBq+raICm5yWv7WtpyTFXasqeqmSPqpq2RCKXD46sxWZonoyo7ja58JUNpkeDtrjgCobgYRPgB92Hbj2tzMQ==; 3:Qp/3NM/M1F5eArB8cPgcB6ekO+oyzoiQrReNJEjmgPC6TmihWPDYDEzlQchRi/SRc0Tyne4+vmx1xvrPMO9TutUD1D9aiZW62+KOglIJLUOdBAZVCu/5qjewBvcWvfs/I2488WfRfzA+5DerzeR6HDgznWnr2GJCWvgCzJU5UJRTymPnGwq4y7NEWuN02IL6Xq8Iw1ttOY41Os06+zIZ0yPoCSgvQv0mSZIaMmCekFXZzNDAvJWD0pFuu4yKm9dIAj9f71ODxGNmDK/bUzUjlw==; 25:QHoegwAuLr0ib34WFP5xBKXJMwOKBNLGA7J45JcrbOPYT2pSMy4UVjF5zl+7RxdvTBgi9UDXTpm/d6jo9socnxuJZbbWsMiD0DD7a6CI3AeJAjldDkgW90ypbmQDhpP86lHMSk9gZSdsuGCh9Hg8qrmabud9VBJrnhKVzFTNwuC+Y4+8Yyn43zeDMtkEt+AtPIn26KlA5OO6TZjhViFC4jZZCnljfmT0k5qDriSf/NY0uyQ61un37V4dhQbf35BD1qpnQ0SrOx2bfHWHXgxVjA==
X-Exchange-Antispam-Report-Test: UriScan:; BCL:0; PCL:0; RULEID:(8251501002);  SRVR:BY2FFO11HUB007; UriScan:(18430343700868);
X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB007; 20:GQpkxbjxjsmvFFJvu4X0L/dzS1QnuspYzD2nZyt8l4LD///22rZmv+0ocV+6FcxX4p/RIBbE85UcePE6TLEABX8prn5Bz1svmg6M9bSfOr/bUbyGaOe/WYu1Iu8bih91B8kobErcnUNDR9jNF4ECsV37KlzYYCHB8RaNIiAenvjm1w7/fOciaZXLjAHEf8xlQvhjH/ln64AaFKevxQ3Dmlh4t51SQQLOGpb2M9dMS2FbaHZg+6k+nAp/AuPwIwvH; 4:FPrp+69f8WPdQ+DxTsJqK5Ek5OB7Zox3+rarOV33kOBoDqJxGkoNP+iv8J4ViNWkKnJpgf/IlQMT71F/1LYUtowgxBeAjZK+XwntNnx9dkwfqMtg1F8atILjf1uusuVbLO53mcs3RYmD6efF/NwP1O7M5KsIUXEEnNNbVKoQY/Lu6pxtgO+9Ux7Rd9nJSftrPFTpQywp/hTLNRcn3Eq07nLixOrDQva4nYCMUZC3dBueRMi/FkDEAYZLYfriHSDL7u/vt7UQfaIkaxpYn8JfrYdX9ng6NlpfEUXVVqRhJ006l+UjjPvlE1k4feOG2enp/xDvO9YHuamnfJK8b0+KxeXeowNVWkpPwPFecawhqoUfaj1pVx2yqjWuBuy9Vr7q5KJskk9qlvZ2KQMrg2/807PdEFf0LGf3uZP5FqdnBZdDRRdrzdRWIseteX5Uv+iq
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:BY2FFO11HUB007; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB007; 
X-Forefront-PRVS: 08062C429B
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2FFO11HUB007; 23:zZTG+E3mL1pUe4Xc3EoJrIYj0OqpBdxV/J7atINE?= =?us-ascii?Q?4LiRDwkDa2qxI+aRbSXjJwvpy5A7CHyRWmY5zdxXfoCGmhu2k0yFqJsyaIuI?= =?us-ascii?Q?GWUS44ZtFRG6e2sFk4KEELiRgYBWPJ/bB25CjfnBrtCIW6N/45IZqARB46q0?= =?us-ascii?Q?ahLrxqDXEmi4BTEf7b9wDz+T1XLbkYXo2x/nA+rk2srfDFn3tXX2L/NWjLlh?= =?us-ascii?Q?uVuNuizWo+1v8xMWHKjorEv3mXCiAlq/+OuEXjODc0Je4KZc/EvoRP6Hq/2W?= =?us-ascii?Q?sapu6pylSqLc6l68tw2ae36QkK/DFVKCA4hF+qu8BLHJXCQyG/9ZtEz96dWU?= =?us-ascii?Q?eOQfvI53x38FFn2RP0HHC1/Eb7SymI02UwB2aEPBqdtHhlehbw2o6m3OgqBB?= =?us-ascii?Q?i2rdu44fK+1P13jz2RQprgxAwF6Nk+fi35xIajBdN01ZMyga3yLaaLhKp0hr?= =?us-ascii?Q?Va3K9o2Is1NTHqDAjrVKvXFrZBjaD+X1lNkcmxP3mRCMN+RLcyFTq5/qLhyS?= =?us-ascii?Q?/r8TnWoO9HWzilrGQJnl1aK414ExT3NGLIq1CXckPmT1M0izqgjOx+6Qiw+5?= =?us-ascii?Q?6nbi9MPUieWpryO468vJF9d6mf46DBlPlWwfFRhSpADVt9YOJBiNJykCKm4L?= =?us-ascii?Q?OvEH9NMNk7PiFB0bFu3NRK9TnV6MoNbFYeatpMbLfKKS+JN29yA33gmOQrTO?= =?us-ascii?Q?DA5ovTgVvH+I9cOtxalNw8Ixg/brneAfSa7u84Ok7EFtbvhF8vkh5bGUe+4J?= =?us-ascii?Q?jyEfl/6LY7U5Tj5uNuk1/ueZAl0l7g5QdhjLfA9sWdnK/k/oUyb2tq5fY1m4?= =?us-ascii?Q?A5+x8mjFl4asWKFB4RnjUcL3NLYAyzKr0O22MbKgfWRjJZq4tP2eWm8FXO9V?= =?us-ascii?Q?iyiCEvtZ4bybzz1EVwD4qvNg6q/D0zy0H4paJ3FG/GlZUeEaT1fAwD+CqMRw?= =?us-ascii?Q?VYYpXN+PxGK3OAljs+h/4UeVgxAmhPP5MWHlcmPfC5F2uveD9RRNcUn22ozh?= =?us-ascii?Q?ni2HGmf3C86cS7vunxsL1vUl9tdYvxalnGJmetBXVwkGlpDyMbDhGsk4pKLT?= =?us-ascii?Q?EaWkCS9y6SYemwHVfnteKKj73B4d4tOhtnbEj/aPSW/mtGzt7eo8/+c69QTl?= =?us-ascii?Q?TQHdWmcMKYdzU4/7i/Kxyqzu192OTAijbuATuyPoY2tWPkLeneaTpz4pIHdJ?= =?us-ascii?Q?xjAHN6kiSdoJcvhLIEsvyEXCBFeK3Y2XJgorwYU76yVewKx59JDt3pPr3SG/?= =?us-ascii?Q?idQmRrxBxJsFNHwoQXNKAJlpfWpCFLRH3uCFNPhNcUQFzqe/9xMSPWlkHlpa?= =?us-ascii?Q?dSnAbpUC/9d6180h51fZRQD6cOA+V9Bo9NW1SnQ1Eq4MpbMXyIDEm+hJu1v+?= =?us-ascii?Q?v2dX4lHFsunXwFWRrHJDog4efcQPb32RYzsdLkaSEzPNVlnM?=
X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB007; 5:tiWEYfDZdLzSAsYlPITA3jTLlYSaPpY9G43RR0oc3HPghSPXlfHw1QU5xWnIESLVv0NiP2Wx0AFE8rXHDScVt3EErq2LwWKR3jUkCjDAO4APHvsbzAuUc2ssFAS7xaH8glGR1aRsm7+tlTF9WNJB6A==; 24:MdOkT/yTHswUTI9jt39fU4mWAdnAuQp9ZHu8udH1FBFl4zfuWyIv3AnHgUc7oM85ikou2GZWALqshyXH3q72Lf+jd7vndNuxqH3A/0YI6YM=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: sprint.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Dec 2015 15:33:46.3112 (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: BY2FFO11HUB007
Archived-At: 
Subject: Re: [Modern] Problem statement draft as working group document
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, 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, 30 Dec 2015 15:33:50 -0000

Thanks Steve.  I've been combing through the document and writing questions=
 and editorial suggestions (in good faith).  I've decided that rather than =
pepper everybody with notes at the end of each day as I generate them, I'll=
 instead try to complete them and send them as a whole.

So far as I've gotten the document looks more like a hand wave in the direc=
tion of particular (but perhaps unimportant?) problems in North America spe=
cifically, and jumps directly to suggesting the framework of a solution.  B=
ut, this is an admittedly premature and biased view based on previous brows=
ing of the problem statement and my experience with the WG charter and the =
generous definition of consensus allowed by the ADs.

It is possible that I will "see the light" and recognize it as an on-coming=
 train (with respect to the problems outlined in the problem statement - no=
t the IETF processes).  If so, my edit suggestions will benefit from some m=
odification and should improve the result you'll see.

I'm trying to have my input completed and ready this week.

Pierce

-----Original Message-----
From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: December 30, 2015 9:21 AM
To: modern@ietf.org
Subject: Re: [Modern] Problem statement draft as working group document

Pierce,

There is no hurry or reason to delay in advancing a draft to becoming a wor=
king group draft.  Doing so does not say that the contents of the draft are=
 finished.  Rather it says that the draft is a good starting point for addr=
essing a working group milestone. Despite Cullen's opinion that the documen=
t is close to ready for WGLC, that is not what we are discussing at this po=
int.  The hurdle for a document being ready for WGLC is much higher than it=
 becoming a working group document.  In fact, not all drafts that become wo=
rking group documents make it to WGLC, much less RFC status.

We had consensus in the working group meeting at IETF 94.  So far I haven't=
 seen arguments saying that the document isn't suitable to become a working=
 group document.  There is good discussion on the content of the draft, but=
 that discussion can continue independent of the status of the draft.

I will wait until after the holiday's to renew this discussion but it appea=
rs to me that we can make the document a working group item.

Regards,

Steve

On 12/22/15 10:54 PM, Gorman, Pierce A [CTO] wrote:
> Cullen,
>
> What's your hurry?  Was there no useful discussion whatsoever since Novem=
ber?
>
> Sent from my iPad
>
>> On Dec 22, 2015, at 3:22 PM, Cullen Jennings  wrote:
>>
>>
>> I and a lot of other people provided input at IETF94 so I did not see an=
y need to say more here.
>>
>> However, there has been nothing new raised on the thread here that had n=
ot been brought prior to IETF94. I think it is very clear the list discussi=
on has not changed the census from the meeting and thus I think this needs =
to be adopted now. What timeline do you have in mind for adopting this?
>>
>> Thanks, Cullen
>>
>>
>> PS - yes the draft-peterson-modern-problems-02 draft looks more than
>> fine for an WG -00 doc, in fact it looks close to ready for WGLC
>>
>>
>>> On Nov 13, 2015, at 2:53 PM, Steve Donovan  w=
rote:
>>>
>>> All,
>>>
>>> During the IETF94 MODERN WG meeting there was consensus that draft-pete=
rson-modern-problems-02 be accepted as a working group document.  This woul=
d be to address the architecture Architecture Overview milestone.
>>>
>>> It was recognized that it is not in final form but would be a good star=
ting point for the architecture overview.
>>>
>>> Please comment on whether or not this should become a working group doc=
ument.
>>>
>>> Regards,
>>>
>>> Steve
>>>
>>> _______________________________________________
>>> Modern mailing list
>>> Modern@ietf.org
>>> https://www.ietf.org/mailman/listinfo/modern
>> _______________________________________________
>> Modern mailing list
>> Modern@ietf.org
>> https://www.ietf.org/mailman/listinfo/modern
> ________________________________
> Switch to Sprint and save 50% on Verizon, AT&T or T-Mobile rates. Your sa=
vings are guaranteed until 2018! Available on most plans. Limited time offe=
r. Exclusions and restrictions apply. See sprint.com/save50 for details.
>
> ________________________________
>
> This e-mail may contain Sprint proprietary information intended for the s=
ole use of the recipient(s). Any use by others is prohibited. If you are no=
t the intended recipient, please contact the sender and delete all copies o=
f the message.
>
> _______________________________________________
> Modern mailing list
> Modern@ietf.org
> https://www.ietf.org/mailman/listinfo/modern

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

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

________________________________

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