From nobody Thu Jul 7 10:33:26 2016 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FED12D572 for ; Thu, 7 Jul 2016 10:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 pljjVxR3C_Tf for ; Thu, 7 Jul 2016 10:33:23 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65FE312D0E4 for ; Thu, 7 Jul 2016 10:33:23 -0700 (PDT) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u67HWQ2J031584; Thu, 7 Jul 2016 13:33:23 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 23x9qpjavy-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 07 Jul 2016 13:33:22 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 7 Jul 2016 13:33:21 -0400 From: "Peterson, Jon" To: Steve Donovan , "modern@ietf.org" Thread-Topic: [Modern] Review of draft-ietf-modern-problem-framework-00.txt Thread-Index: AQHRzk2W0VnsFaP+xEeTcvTqXwlhyKANHGCA Date: Thu, 7 Jul 2016 17:33:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.185] Content-Type: multipart/alternative; boundary="_000_D3A3E0541A50BBjonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-07_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607070158 Archived-At: Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-00.txt X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Managing, 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, 07 Jul 2016 17:33:25 -0000 --_000_D3A3E0541A50BBjonpetersonneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Steve, I cleaned these up. Jon Peterson Neustar, Inc. From: Modern > on b= ehalf of Steve Donovan > Date: Friday, June 24, 2016 at 12:21 PM To: "modern@ietf.org" > Subject: [Modern] Review of draft-ietf-modern-problem-framework-00.txt I have reviewed draft-ietf-modern-problem-framework-00.txt. This document = is in great shape and I only have editorial comments as follows. Regards, Steve ----- Section 1: s /familiar from the /familiar to the/ s/ manenr/manner/ s/evolvling/evolving/ Section 2.1 s/assginees/assignees/ s/entitiy/entity/ Section 3 Need references for DRINKS and WEIRDS Section 4.1.4 s/Aquiring/Acquiring/ Section 4.1.5 s/wtih/with/ Section 4.2.1.2 s/Regisrar/Registrar/ Section 4.1.2.3 s/could could/could/ Section 4.3.2 s/to access to this/to access this/ --_000_D3A3E0541A50BBjonpetersonneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Thanks Steve, I cleaned these up.

Jon Peterson
Neustar, Inc.

From: Modern <modern-bounces@ietf.org> on behalf of Steve= Donovan <srdonovan@usdonova= ns.com>
Date: Friday, June 24, 2016 at 12:2= 1 PM
To: "modern@ietf.org" <= modern@ietf.org>
Subject: [Modern] Review of draft-i= etf-modern-problem-framework-00.txt

I have reviewed draft-ietf-modern-problem-framework-00.txt.  This document is i= n great shape and I only have editorial comments as follows.

Regards,

Steve

-----

Section 1:

s /familiar from the /familiar to the/
s/ manenr/manner/
s/evolvling/evolving/

Section 2.1
s/assginees/assignees/
s/entitiy/entity/

Section 3
Need references for DRINKS and WEIRDS

Section 4.1.4
s/Aquiring/Acquiring/

Section 4.1.5
s/wtih/with/

Section 4.2.1.2
s/Regisrar/Registrar/

Section 4.1.2.3
s/could could/could/

Section 4.3.2
s/to access to this/to access this/
 --_000_D3A3E0541A50BBjonpetersonneustarbiz_-- From nobody Thu Jul 7 11:38:21 2016 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE9212D13B for ; Thu, 7 Jul 2016 11:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Ww9sxrqn7vA6 for ; Thu, 7 Jul 2016 11:38:17 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0120.outbound.protection.outlook.com [104.47.38.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 2F1F812D1AC for ; Thu, 7 Jul 2016 11:38:17 -0700 (PDT) Received: from BN1BFFO11FD052.protection.gbl (10.58.144.31) by BN1BFFO11HUB009.protection.gbl (10.58.144.156) with Microsoft SMTP Server (TLS) id 15.1.523.9; Thu, 7 Jul 2016 18:38:15 +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 BN1BFFO11FD052.mail.protection.outlook.com (10.58.145.7) with Microsoft SMTP Server (TLS) id 15.1.523.9 via Frontend Transport; Thu, 7 Jul 2016 18:38:15 +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 u67IbR7K025608; Thu, 7 Jul 2016 13:38:14 -0500 Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by plsapdm2.corp.sprint.com with ESMTP id 241vh7r05m-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 07 Jul 2016 13:38:14 -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.1178.4; Thu, 7 Jul 2016 14:38:12 -0400 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.1178.000; Thu, 7 Jul 2016 13:38:12 -0500 From: "Gorman, Pierce A [CTO]" To: "Peterson, Jon" , Steve Donovan , "modern@ietf.org" Thread-Topic: [Modern] Review of draft-ietf-modern-problem-framework-00.txt Thread-Index: AQHRzk2U1S3ChqfLdUehwOlnB0jAB6ANooUA//+2tyA= Date: Thu, 7 Jul 2016 18:38:12 +0000 Message-ID: <8caed92a03be4425ae31261887b475b7@PLSWE13M08.ad.sprint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.44] Content-Type: multipart/alternative; boundary="_000_8caed92a03be4425ae31261887b475b7PLSWE13M08adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.172.38; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(7916002)(2980300002)(438002)(189002)(199003)(377454003)(6806005)(19580395003)(81166006)(81156014)(19580405001)(92566002)(11100500001)(24736003)(7696003)(2906002)(106116001)(30436002)(8676002)(512954002)(107886002)(76176999)(54356999)(230783001)(97736004)(5250100002)(50986999)(19625215002)(189998001)(106466001)(5001770100001)(16236675004)(4546004)(586003)(102836003)(19300405004)(2900100001)(87936001)(3846002)(7846002)(260700001)(6116002)(2950100001)(84326002)(2501003)(551544002)(7736002)(5003600100003)(8936002)(68736007)(86362001)(108616004)(33646002)(790700001)(356003)(15975445007); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB009; H:plsapdm2.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD052; 1:QjtppHfUCVQpYnKLES7WUvGmHN82mGSJbA+skCyfBVNTGjHd+9M71QMh0fKP469t9eyk1xdVwGcEq9RdtBLKlLExpO7gZ8QdrC4wJxlgt1M70H8qyt9CGxZZIzz2OgY/ILJ5AO5yEPxhETG4FKBjEOAvUFzsnHSF8mrVJWAplOOPW8oiifnubU0Wi0uigThRFrEC5T6X4R+KCIsAlLEBR6iKAS/vW+oSEDGI7CNczPBfCqVFAKpr33q91e6ojjBFxphHXwU9fXnC2usrJmBLgUzNPBmJdPWAs5VMJ3McNYRZrwoAyYXAZMf8dwX+Hh/LCGR+d8z/441vVzhaEmW41AeGeuj3mCn/AHGDfkGnoEwwPsoha/dVUAU2LfltYCXH7Y8HrNAlEV1zx2POwBhvhYotkw+UZTwc7m/hg3VTrum90eDMCmLznFdf5VRZMliXkaLhYIT5qfzF1T003jZTzj5TqTDBQWeFQ6W1gi4Z+A8UhxyduumAfis0Zo0r6YEEL1lYzAz0VGi6q19fcRRlGRGXj1GjTo/GX97A5uynONl5FPHfQGQTCAO6Xy1ayO4J X-MS-Office365-Filtering-Correlation-Id: 1f46e877-08a9-4edf-c3c3-08d3a695dbb4 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB009; 2:UtqwRlrduw1Ft88gbGGX/8h72C4uM9IRYHGYnUfUj3h57rXtw6X6maMaj5m9T5zNaWyUZJwef8iZE/iLnfM5TJ8Q+WnpcDseQc5b7nv+g7wKWXCdtuMm/UfNY5YIdDq6Qb06myyCxXob7rQWL+3J+rbyQhq9COvaKvwhx/0BQr/AI7Z9bdkJpjSysN5aCBFM; 3:Hw0U1w5JsRD7pges7lJsxrS6xVkOi1CELoTOliJhIM1z2GlNjMnLQnudSsUbjOKNmGF3oiIYuoE48iaJI5Ad4Z1CrUBAwySBD6fCxdIOOltU18RhS/p1Td1vIuNDAdinNHDnwuP2au3dLL2jG7AGC6JanaFHoVETOM6Bm/hvqaEQWFd60zr5DF8vh0PXL3MaCWIQllU1Fwk6njtz3lVZj39uqdVumNZ2jAtuRGCP3RlQw3GsseAIL2sN1JocLF79TQZJLUq0TmYnhRi4AmaCcA== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BN1BFFO11HUB009; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1BFFO11HUB009; 25:BE50spv72Mg3Njhoxlsy90TZk7rOQyVEj1LADLb?= =?us-ascii?Q?09wp412FiYYgWCQYhIuQJ58fxJmKcFTiQWLsB5AY0YVVzGYUxcCJLNTwYm9q?= =?us-ascii?Q?j+muqIflolbbykfl4RcwFO1PRC9Pn8afXLYj9OX66k4tCKYZlulD8nwH1bW3?= =?us-ascii?Q?MbUkLBjpD6sOoc8w+X4P+qR8zpi+P61y2Dga59ONSpjd+UKMMp9Ui37CiSwM?= =?us-ascii?Q?wgkshAz9uD0szbbXQ1+cZDrQ+QDAnnQKFCFeLF21s9NmXIctk98clHuf7pss?= =?us-ascii?Q?OCWOL3xf5NSnQxGCuYxWehAyxBEuexCEu2Qy2a3377byPWPQtRC/k72+gws6?= =?us-ascii?Q?u5UzUPBQ0FwblSVWSLGzJ/+je9Y5jkYjQOk+Js1I696oWdqJSYzOuw7hcyBG?= =?us-ascii?Q?uPBAaXC6VnqsLSh/HuO+EN7OglNYJt9Mz9oGpJuVQKlczYcnqwlxlGAXDmyu?= =?us-ascii?Q?3l8qU8pW0Yi3IjJ0CYJUXIIcrNCfyDH7DdHaTT/41g9LGcqxP73uJuPgf1wC?= =?us-ascii?Q?a5VQpK3uNAlEtmvkx2WOYGEDaoAqGQaM/gLoZMJwAlyuiT1fmhhxi0HjErFm?= =?us-ascii?Q?zzBMjmydXGc3Sbz0y7arIlB4JqeATL3pHgyqZu/gilKiAFxkAvkLWUBkytN8?= =?us-ascii?Q?sWybH0rJlR9FH1257BTc564KTOFlnIX2SewyJg/2yNRHJmgh8f1ivYV6s5V5?= =?us-ascii?Q?no30U3GzNsSX2C/v6iMxQRAbuYwD8+L+fmVCoy8VGhOhb6111UPBzbWt4LON?= =?us-ascii?Q?dTzxcGKPfo5w0BDdtrWzjdYx+8nPncF5OlLVUx5+VKikfY4l6hkqvKekwlIk?= =?us-ascii?Q?65ZzORRe29Q0aboi9wUwvkXJjpiyzitnkPZOaGPOTwCwLzBk0JkhZfF5I4XE?= =?us-ascii?Q?nApnQCaxgrw+nRh4ZxK8Oegz4wVhA7uyxtPUj+RVuW/3YOOJo7bB8fH4ILC/?= =?us-ascii?Q?hz/o7D/HTncXKRUSOcJ4fIkPutEjmpQXKCWgmEV4GN6YN1FWrKb+maQn12p+?= =?us-ascii?Q?HVtydT4fFUoqttWix0Nn0E21s?= X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB009; 20:BLJjXsaJ83DNDyWRrgJQj5eH1rzWyfL+0mETOgjrYDP9geTe6iHcDVIgzWKaQWYwFlGr2wqo7DFnik7k/0rMGGR6ieJiL6Kn4IKhQwCHzgcZBCtwf+w/oUCo65ru3svrw1ktFjpqi1q+rBpNABGweU1NWnEQvhSdyb90KK3+DkAfrhyRNOs35mczPtkwjk6LqO4bqFCzAzfUo/ggAVfHn53aze2ahzANHnGSrcia880buMMljOmeuRUWz5C+C3B/u8k6G0XpX5eaZr2wLpy6Y86j8r/qHFnymlISZmHH0j9hTHGfzwcY+IjM5taUt9OzhIra7aiL6mWPO3lXApWGA+t79c3VmPsgAlC/OpuyBP6Ul2Cx8KsZ1suikLWpA2MqmvcJhyL/vjnUeGEGHD+dR1KJyyzCMccKdZOlHdYVDPo=; 4:2OdBlaJKf+sfKXqFDI0h5vFv6yIpEhTZqG6fDRWkSHpCMLQ4AThX4yp7Sjt9qSjsgLm4+mTC9uNStL6t2NTMXRkCmEwHaMGUYIE658oPzIJzcrLvjot2Yb+TLHtubaHWFjMGUMlpMxU7BaH1QvvTguF9vXLtXQGzD8BjCatP+W1zqtk6jVNKloC3u1ZJjuHpUJZkLBDHvddZOdRoSyj/3qlWXBlHAheW7EXKfC19Ypg2qiuFCWWxFhd3faf6cHn1DcQuRke2VjIThGEHMFf2KSeBX6Uoeqn1XToviUImo2Jqz/HvQyBSpH9RnzXAATrIBhd2eR5ALpX+bBsIDVhytXOgIXCWB1AIKmkW4mNUtQK6jHSsLx/wZVFA6dEjEIinDpEn+3IOcxmwJEeOZxMnk1AinGyzIWgg3WF4e7YW9Ne7GLb2qBecXKecGbaHfCf1Lc6I2N2zAJcNAqig9kwuPIaVJZTrKuGRFH5IWMaIQQDYVOJG6vBY04yFPGe5AQLuHt+BtdQfA7bG1ppu+VsTbg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13018025)(8121501046)(5005006)(13023025)(13024025)(13015025)(13017025)(10201501046)(3002001)(6055026); SRVR:BN1BFFO11HUB009; BCL:0; PCL:0; RULEID:; SRVR:BN1BFFO11HUB009; X-Forefront-PRVS: 0996D1900D X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1BFFO11HUB009; 23:pg5sch2M/TwRn2QsWv8RoE2nG/pTu5NfAdcxu4U?= =?us-ascii?Q?edhaOoRT7uI0o2UzR8IJ6+aWgpT5wYiOLw/eQwIjxJdztOhlHnYZNmGPdDMH?= =?us-ascii?Q?vu1w7CE6T5/Y9zB0fIg+6u/MlMQ4Wj6tG8acwP66EOZMC1wVyXoCVXarnvQq?= =?us-ascii?Q?GZX5x4LKigpmcmoqedm7nyJUC0M93aOuBw9xVVlqPNIG6kM7eQjpeEydtAWb?= =?us-ascii?Q?sAVbtFDU6o1cYGySKbbnHuRrf508lS+fUF0osENyG38TVXCaCHGvAQuNjNzJ?= =?us-ascii?Q?73KDla6AOZJ/RVGOP7q+oa/FgrrfvV40+Fr3iaIFjOU/XHXeX2xTIKgFvMJf?= =?us-ascii?Q?qlZqdPzdEgHetBjSnZJ0M74nusJiYks/+keFXVMsE1Sjny5Sbk8L45vz6UyX?= =?us-ascii?Q?q9LHqtu1BdE+NnSgDZyxkEOc3Si4sEqRztiwYJH/N6Lyx01txuC4zH6no/5o?= =?us-ascii?Q?xN1rqoNNZ6BlDphFo0I8Ejo3xwwykIVdXsMPiqsBJgZwAi2PFAvb6DUx/7c+?= =?us-ascii?Q?s6fetYnEJA1VnFh6NXnxg6eRAKGa8fcOvcazn7PJHZ3qheR89l7auQ6sWEkM?= =?us-ascii?Q?lzCrzBVACYlEjNa/IXCg1pNNLu/VqGocqoQK/9JuYej1zrHlpbvW99S259/r?= =?us-ascii?Q?ulVx0RGLSahM5kpIoz8RKc4GnH5pKUZTJLm2MBoHxKx3u4Zh2R98bnby7nYe?= =?us-ascii?Q?Jw4b4iTHXm6xpAtO7ApJCFF8JFkz+TaP06TsBiIDrAFUtxOt8Oy6clNv0bOl?= =?us-ascii?Q?EPb9+qHy3Rgk1uSYogTZNgtED2//rAoMStL8dYuhxi+uq7vuoGKZGEyKMSDm?= =?us-ascii?Q?y+fPf/EQotSbXAEmIeqc+VEJ77hLfJwtP4oxWie8ZqaOB+EjvXHzDZ9jIthA?= =?us-ascii?Q?5Z6nqwYLfhHcqeXQtUv92Y5Z9Vqa94Eh6fVivnQ5vmYWpWEInaUImVJS7UgQ?= =?us-ascii?Q?AuAphV39eYth8yiOM+BgnA139MNDy8UdfGNnixl5PxmWBlqfNNmr4So5Kvog?= =?us-ascii?Q?j1HpdGG/UjRjIEFWSdv9GG64yMovYrFOi2rF59gKRDpqnu2O00IoAdhLAGF6?= =?us-ascii?Q?TIcq1TgGMuC3GfSrj3pormkprjx30oRcOtoI4GTf1yhwWHwOdQuuOZHbMjU7?= =?us-ascii?Q?lrvbC4/jItbsmutcKoip0yIThdPKI6KEVo6eF4Z4fnxJm+ZMu3IcfG5Nscx0?= =?us-ascii?Q?CEXKjkSdbfwT3cUGMP13In7vmPWCDjq1DSk2WQlp2b9/dy63/QiFw4EsT9ID?= =?us-ascii?Q?nV1KWvFXcBDaMeQC1zh0zm7vJhZiMlcWPT+6jpoAgpPfJ7CmQAL69RuCIMXT?= =?us-ascii?Q?/dXgxVW8we38CbiqiB8bkgYouIrMLXNv35zdsVGXH8M2L8N8LDW/kUaN3/db?= =?us-ascii?Q?T3RM0isDv/Gpwd787G+lmBJqxymYq2u4S9NWO8KQBzhHqtbV2?= X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB009; 6:9eitp2xqRY+xDT+Z+kDg84nMFwwY9pklTJyOj5/FbIncTLJjUVdfEOpBcwFfsEjfgTSPbOWDthoiN5d3DE14ns/7jg80dtosqnHl0bo6uGdmL6YNEWmshnuxUmM6oDeZZ0k6ZcuzYPEeaFCvhArOWwIYcfTkkjKO35eyYmImgMf2N+NCF8teEXFzad9aJ6cVv4TBDCuMv9ayUT+IyeIQFq+aeKjJqJ4nZqiMM26HAwSg6tW2s6a6guJCod5mfdS9g3RW9MTiTCxZMYEE0O9LVYnPSeR8bbZcphiSXBsBFmE1KgH4K8QlbwfsJINcz+tKFSzg61lWNyYNMdHMUxKYTSGlQVu1UNXuh4X2/KCsY6E=; 5:NTkL5PwE4IWgCGMBb5SUG6Q4fA8ngOWeJ8aqKZ3xaSG2vd8WpaFOqvuZdG4GL8FIhFKxIpctARjQB1Ii410B1K7Y100z0A64odNAa2zMVeVTwpO/G0fGtd8nYr9wLChZOer17A4zELSRyonvIV0oqA==; 24:Btlq+XVaZkQBdmkeFtrJBIlwqDRm1Y1y3Fr0rW7YClrz7UlSp7jakiSct6eJLP36QKjQxWeomgEj5Jn6WP7pCNc/6YrLzHCZoowDCZoFt98=; 7:1umBil2pkiu9G589+h17OS+0zKuhxwLwqKH99UDudignXuIVUcmFrNy0yO/JoLrxIxLahyYA4EHUqCBjf2+a/h7CcGfwP4a5pokWrVK3Up6RfNt7S+S5bmYYA/hky7375l+DrQnIyzzYMpQxT24FUfUAEUoZCjNdIoFp96FljVj/Mn0E6izCAd1x1/pWnxMTFIXrbXOCre9EiyhnXxX8yHVWz3z9Qe/HqdIfCS9mcsFX9pEzvjbz2hQ2bcGnbTab SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jul 2016 18:38:15.4050 (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: BN1BFFO11HUB009 Archived-At: Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-00.txt X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Managing, 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, 07 Jul 2016 18:38:20 -0000 --_000_8caed92a03be4425ae31261887b475b7PLSWE13M08adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I haven't read the most current version, but I think it's fair to say I've = provided most of the public non-political feedback to MODERN so far. The last comments I made advocated for the use of .name. domain name space = (or a new name space) tied to telephone numbers with the concept of MODERN = hosting Communications Reachability Information (CRI) and that index keys i= nto a CRI database could be passwords which could also be telephone numbers= . The idea was cheerfully disregarded but I will bring it up again. The MODE= RN "problem statement" is a solution architecture (not a problem statement)= , and it's inadequate, and centric to NANP telephony considerations. If you want a globally usable telephone number routing information model fo= r IP-based telecommunications and you want to more usefully solve problems = like calling identity authentication (globally) and non-geographic number p= ortability (for NANP), you should seriously be looking at multi-factor auth= entication for routing information queries. Factors such as who do you thi= nk you're calling? And, what is the number [password] you think is associat= ed with them? You send a query to the CRI and you only know one factor (e.g., telephone n= umber)? That provides you an index into the least useful telecommunication= s information. Perhaps only a telephone number into a SPAM-only voicemail = box or voice-to-text-to-SPAM-text-box or whatever the user has defined that= protects them from unauthorized and unauthenticated communications attempt= s. Create a multi-factor communications model (which SIP and other communi= cations protocols easily and commonly support) and you can have a meaninful= impact on global robo-calling and robo-texting SPAM. I have 3 main telephone numbers that are unique to me. Very few people hav= e all 3. I compartmentalize my communications based on whether they are pr= ivate, family, or business. I could easily want or have more. Many people= do. Very few people purposefully distribute all of their telephone number= s, e-mail addresses, social network personas, et cetera to all of their pri= vate, family, and work contacts. If you want to give users globally, the world over, control over CRI, build= a model that addresses their communications reachability needs, not their = voice telephony needs. Regards, Pierce From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: July 07, 2016 12:33 PM To: Steve Donovan ; modern@ietf.org Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-00.txt Thanks Steve, I cleaned these up. Jon Peterson Neustar, Inc. From: Modern > on b= ehalf of Steve Donovan > Date: Friday, June 24, 2016 at 12:21 PM To: "modern@ietf.org" > Subject: [Modern] Review of draft-ietf-modern-problem-framework-00.txt I have reviewed draft-ietf-modern-problem-framework-00.txt. This document = is in great shape and I only have editorial comments as follows. Regards, Steve ----- Section 1: s /familiar from the /familiar to the/ s/ manenr/manner/ s/evolvling/evolving/ Section 2.1 s/assginees/assignees/ s/entitiy/entity/ Section 3 Need references for DRINKS and WEIRDS Section 4.1.4 s/Aquiring/Acquiring/ Section 4.1.5 s/wtih/with/ Section 4.2.1.2 s/Regisrar/Registrar/ Section 4.1.2.3 s/could could/could/ Section 4.3.2 s/to access to this/to access this/ ________________________________ 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_8caed92a03be4425ae31261887b475b7PLSWE13M08adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I haven’t read the most current v= ersion, but I think it’s fair to say I’ve provided most of the = public non-political feedback to MODERN so far.

 

The last comments I made advocated for = the use of .name. domain name space (or a new name space) tied to telephone= numbers with the concept of MODERN hosting Communications Reachability Information (CRI) and that index keys into a CRI database cou= ld be passwords which could also be telephone numbers.

 

The idea was cheerfully disregarded but= I will bring it up again.  The MODERN “problem statement”= is a solution architecture (not a problem statement), and it’s inadequate, and centric to NANP telephony considerations.

 

If you want a globally usable telephone= number routing information model for IP-based telecommunications and you w= ant to more usefully solve problems like calling identity authentication (globally) and non-geographic number portability (= for NANP), you should seriously be looking at multi-factor authentication f= or routing information queries.  Factors such as who do you think you&= #8217;re calling? And, what is the number [password] you think is associated with them?

 

You send a query to the CRI and you onl= y know one factor (e.g., telephone number)?  That provides you an inde= x into the least useful telecommunications information.  Perhaps only a telephone number into a SPAM-only voicemail box or voice-to= -text-to-SPAM-text-box or whatever the user has defined that protects them = from unauthorized and unauthenticated communications attempts.  Create= a multi-factor communications model (which SIP and other communications protocols easily and commonly support)= and you can have a meaninful impact on global robo-calling and robo-textin= g SPAM.

 

I have 3 main telephone numbers that ar= e unique to me.  Very few people have all 3.  I compartmentalize = my communications based on whether they are private, family, or business.  I could easily want or have more.  Many people do.=   Very few people purposefully distribute all of their telephone numbe= rs, e-mail addresses, social network personas, et cetera to all of their pr= ivate, family, and work contacts.

 

If you want to give users globally, the= world over, control over CRI, build a model that addresses their communica= tions reachability needs, not their voice telephony needs.

 

Regards,

 

Pierce

 

From:= Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: July 07, 2016 12:33 PM
To: Steve Donovan <srdonovan@usdonovans.com>; modern@ietf.org<= br> Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-= 00.txt

 

&n= bsp;

Thanks = Steve, I cleaned these up.

&n= bsp;

Jon Pet= erson

Neustar= , Inc.

&n= bsp;

From= : Modern <modern-bounces@ietf.org> on beh= alf of Steve Donovan <srdono= van@usdonovans.com>
Date: Friday, June 24, 2016 at 12:21 PM
To: "modern@ietf.org&quo= t; <modern@ietf.org>
Subject: [Modern] Review of draft-ietf-modern-problem-framework-00.t= xt

&n= bsp;

I have = reviewed draft-ietf-modern-problem-framework-00.txt.  This document is in = great shape and I only have editorial comments as follows.

Regards,

Steve

-----

Section 1:

s /familiar from the /familiar to the/
s/ manenr/manner/
s/evolvling/evolving/

Section 2.1
s/assginees/assignees/
s/entitiy/entity/

Section 3
Need references for DRINKS and WEIRDS

Section 4.1.4
s/Aquiring/Acquiring/

Section 4.1.5
s/wtih/with/

Section 4.2.1.2
s/Regisrar/Registrar/

Section 4.1.2.3
s/could could/could/

Section 4.3.2
s/to access to this/to access this/



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_8caed92a03be4425ae31261887b475b7PLSWE13M08adsprintcom_-- From nobody Thu Jul 7 13:58:56 2016 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85E512D0CD for ; Thu, 7 Jul 2016 13:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 aDB3EWZ3sSsi for ; Thu, 7 Jul 2016 13:58:51 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96C5412D611 for ; Thu, 7 Jul 2016 13:58:51 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u67KrFoJ022127; Thu, 7 Jul 2016 16:58:50 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 23x8dh4p81-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 07 Jul 2016 16:58:50 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 7 Jul 2016 16:58:47 -0400 From: "Peterson, Jon" To: "Gorman, Pierce A [CTO]" , Steve Donovan , "modern@ietf.org" Thread-Topic: [Modern] Review of draft-ietf-modern-problem-framework-00.txt Thread-Index: AQHRzk2W0VnsFaP+xEeTcvTqXwlhyKANHGCAgACHgQD//7HpgA== Date: Thu, 7 Jul 2016 20:58:46 +0000 Message-ID: References: <8caed92a03be4425ae31261887b475b7@PLSWE13M08.ad.sprint.com> In-Reply-To: <8caed92a03be4425ae31261887b475b7@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.6.3.160329 x-originating-ip: [10.96.12.185] Content-Type: multipart/alternative; boundary="_000_D3A40D551A5105jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-07_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607070186 Archived-At: Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-00.txt X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Managing, 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, 07 Jul 2016 20:58:55 -0000 --_000_D3A40D551A5105jonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think the only reason your idea here is being "cheerfully discarded," as = you put it, is that we're just not on the same page about what is an archit= ecture, versus a framework, versus a solution. What you're describing goes = beyond a problem statement, beyond even proposing an architecture or protoc= ol solution - it sketches an actual implementation that someone could offer= as a commercial product. We don't make those at the IETF. The irony in this misalignment of our understanding of working group's job = is that the MODERN charter is probably compatible with what you're proposin= g, as far as I can tell. A .name namespace allocated for this purpose of ex= posing reachability information would be an implementation of the "retrieva= l interface" component of the MODERN framework described in the problem sta= tement. The question of what "factors" you include in a query to the retrie= val interface is indeed one of the big ones we're interested in exploring -= we hope to eventually produce an information model that will capture what = those factors would be. We want to create an information model versatile en= ough to work with a number of distinct bindings (that is, protocols that mi= ght carry the query). But retrieval is only one component of the framework = we're developing, as we're also concerned with how identifiers get allocate= d (maybe how those .name domains get assigned?) and what information gets p= rovisioned against them (maybe what provisioning occurs so that your "facto= rs" help you get the reachability information you need?). So again, it's not that I'm even necessarily opposed to what you're proposi= ng, you're just not looking at the same parts of the problem that I am, and= you're apparently focused on a narrow way of implementing this. Implementi= ng will be the easy part. Getting the information model right is hard, and = that's the work we're chartered to do. Jon Peterson Neustar, Inc. From: "Gorman, Pierce A [CTO]" > Date: Thursday, July 7, 2016 at 11:38 AM To: Jon Peterson = >, Steve Donovan = >, "modern@ietf.org" > Subject: RE: [Modern] Review of draft-ietf-modern-problem-framework-00.txt I haven=92t read the most current version, but I think it=92s fair to say I= =92ve provided most of the public non-political feedback to MODERN so far. The last comments I made advocated for the use of .name. domain name space = (or a new name space) tied to telephone numbers with the concept of MODERN = hosting Communications Reachability Information (CRI) and that index keys i= nto a CRI database could be passwords which could also be telephone numbers= . The idea was cheerfully disregarded but I will bring it up again. The MODE= RN =93problem statement=94 is a solution architecture (not a problem statem= ent), and it=92s inadequate, and centric to NANP telephony considerations. If you want a globally usable telephone number routing information model fo= r IP-based telecommunications and you want to more usefully solve problems = like calling identity authentication (globally) and non-geographic number p= ortability (for NANP), you should seriously be looking at multi-factor auth= entication for routing information queries. Factors such as who do you thi= nk you=92re calling? And, what is the number [password] you think is associ= ated with them? You send a query to the CRI and you only know one factor (e.g., telephone n= umber)? That provides you an index into the least useful telecommunication= s information. Perhaps only a telephone number into a SPAM-only voicemail = box or voice-to-text-to-SPAM-text-box or whatever the user has defined that= protects them from unauthorized and unauthenticated communications attempt= s. Create a multi-factor communications model (which SIP and other communi= cations protocols easily and commonly support) and you can have a meaninful= impact on global robo-calling and robo-texting SPAM. I have 3 main telephone numbers that are unique to me. Very few people hav= e all 3. I compartmentalize my communications based on whether they are pr= ivate, family, or business. I could easily want or have more. Many people= do. Very few people purposefully distribute all of their telephone number= s, e-mail addresses, social network personas, et cetera to all of their pri= vate, family, and work contacts. If you want to give users globally, the world over, control over CRI, build= a model that addresses their communications reachability needs, not their = voice telephony needs. Regards, Pierce From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: July 07, 2016 12:33 PM To: Steve Donovan >; modern@ietf.org Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-00.txt Thanks Steve, I cleaned these up. Jon Peterson Neustar, Inc. From: Modern > on b= ehalf of Steve Donovan > Date: Friday, June 24, 2016 at 12:21 PM To: "modern@ietf.org" > Subject: [Modern] Review of draft-ietf-modern-problem-framework-00.txt I have reviewed draft-ietf-modern-problem-framework-00.txt. This document = is in great shape and I only have editorial comments as follows. Regards, Steve ----- Section 1: s /familiar from the/familiar to the/ s/ manenr/manner/ s/evolvling/evolving/ Section 2.1 s/assginees/assignees/ s/entitiy/entity/ Section 3 Need references for DRINKS and WEIRDS Section 4.1.4 s/Aquiring/Acquiring/ Section 4.1.5 s/wtih/with/ Section 4.2.1.2 s/Regisrar/Registrar/ Section 4.1.2.3 s/could could/could/ Section 4.3.2 s/to access to this/to access this/ ________________________________ 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_D3A40D551A5105jonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <74E27682C50D2B478844EDF418B330E7@neustar.biz> Content-Transfer-Encoding: quoted-printable

I think the only reason your idea here is being "cheerfully disca= rded," as you put it, is that we're just not on the same page about wh= at is an architecture, versus a framework, versus a solution. What you're d= escribing goes beyond a problem statement, beyond even proposing an architecture or protocol solution - it sketches a= n actual implementation that someone could offer as a commercial product. W= e don't make those at the IETF.

The irony in this misalignment of our understanding of working group's= job is that the MODERN charter is probably compatible with what you're pro= posing, as far as I can tell. A .name namespace allocated for this purpose = of exposing reachability information would be an implementation of the "retrieval interface" componen= t of the MODERN framework described in the problem statement. The question = of what "factors" you include in a query to the retrieval interfa= ce is indeed one of the big ones we're interested in exploring - we hope to eventually produce an information model that will c= apture what those factors would be. We want to create an information model = versatile enough to work with a number of distinct bindings (that is, proto= cols that might carry the query). But retrieval is only one component of the framework we're developing, as = we're also concerned with how identifiers get allocated (maybe how those .n= ame domains get assigned?) and what information gets provisioned against th= em (maybe what provisioning occurs so that your "factors" help you get the reachability information= you need?).

So again, it's not that I'm even necessarily opposed to what you're pr= oposing, you're just not looking at the same parts of the problem that I am= , and you're apparently focused on a narrow way of implementing this. Imple= menting will be the easy part. Getting the information model right is hard, and that's the work we're chartered t= o do.

Jon Peterson
Neustar, Inc.

From: "Gorman, Pierce A [CTO]&= quot; <Pierce.Gorman@sprint.= com>
Date: Thursday, July 7, 2016 at 11:= 38 AM
To: Jon Peterson <jon.peterson@neustar.biz>, Steve Donov= an <srdonovan@usdonovans.com= >, "modern@ietf.org"= ; <modern@ietf.org>
Subject: RE: [Modern] Review of dra= ft-ietf-modern-problem-framework-00.txt

I haven=92t read the most current versi= on, but I think it=92s fair to say I=92ve provided most of the public non-p= olitical feedback to MODERN so far.

 

The last comments I made advocated for = the use of .name. domain name space (or a new name space) tied to telephone= numbers with the concept of MODERN hosting Communications Reachability Information (CRI) and that index keys into a CRI database cou= ld be passwords which could also be telephone numbers.

 

The idea was cheerfully disregarded but= I will bring it up again.  The MODERN =93problem statement=94 is a so= lution architecture (not a problem statement), and it=92s inadequate, and centric to NANP telephony considerations.

 

If you want a globally usable telephone= number routing information model for IP-based telecommunications and you w= ant to more usefully solve problems like calling identity authentication (globally) and non-geographic number portability (= for NANP), you should seriously be looking at multi-factor authentication f= or routing information queries.  Factors such as who do you think you= =92re calling? And, what is the number [password] you think is associated with them?

 

You send a query to the CRI and you onl= y know one factor (e.g., telephone number)?  That provides you an inde= x into the least useful telecommunications information.  Perhaps only a telephone number into a SPAM-only voicemail box or voice-to= -text-to-SPAM-text-box or whatever the user has defined that protects them = from unauthorized and unauthenticated communications attempts.  Create= a multi-factor communications model (which SIP and other communications protocols easily and commonly support)= and you can have a meaninful impact on global robo-calling and robo-textin= g SPAM.

 

I have 3 main telephone numbers that ar= e unique to me.  Very few people have all 3.  I compartmentalize = my communications based on whether they are private, family, or business.  I could easily want or have more.  Many people do.=   Very few people purposefully distribute all of their telephone numbe= rs, e-mail addresses, social network personas, et cetera to all of their pr= ivate, family, and work contacts.

 

If you want to give users globally, the= world over, control over CRI, build a model that addresses their communica= tions reachability needs, not their voice telephony needs.

 

Regards,

 

Pierce

 

From:= Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: July 07, 2016 12:33 PM
To: Steve Donovan <sr= donovan@usdonovans.com>; modern@ietf.org
Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-= 00.txt

 

&n= bsp;

Thanks = Steve, I cleaned these up.

&n= bsp;

Jon Pet= erson

Neustar= , Inc.

&n= bsp;

From= : Modern <modern-bounces@ietf.org> on beh= alf of Steve Donovan <srdono= van@usdonovans.com>
Date: Friday, June 24, 2016 at 12:21 PM
To: "modern@ietf.org&quo= t; <modern@ietf.org>
Subject: [Modern] Review of draft-ietf-modern-problem-framework-00.t= xt

&n= bsp;

I have = reviewed draft-ietf-modern-problem-framework-00.txt.  This document is in = great shape and I only have editorial comments as follows.

Regards,

Steve

-----

Section 1:

s /familiar from the/familiar to the/
s/ manenr/manner/
s/evolvling/evolving/

Section 2.1
s/assginees/assignees/
s/entitiy/entity/

Section 3
Need references for DRINKS and WEIRDS

Section 4.1.4
s/Aquiring/Acquiring/

Section 4.1.5
s/wtih/with/

Section 4.2.1.2
s/Regisrar/Registrar/

Section 4.1.2.3
s/could could/could/

Section 4.3.2
s/to access to this/to access this/



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_D3A40D551A5105jonpetersonneustarbiz_-- From nobody Thu Jul 7 14:38:20 2016 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6023812D66E for ; Thu, 7 Jul 2016 14:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 bEyruCK6s9T8 for ; Thu, 7 Jul 2016 14:38:13 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0128.outbound.protection.outlook.com [104.47.32.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E50312D68D for ; Thu, 7 Jul 2016 14:38:13 -0700 (PDT) Received: from BL2FFO11FD038.protection.gbl (10.173.160.34) by BL2FFO11HUB042.protection.gbl (10.173.161.0) with Microsoft SMTP Server (TLS) id 15.1.523.9; Thu, 7 Jul 2016 21:38:11 +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 BL2FFO11FD038.mail.protection.outlook.com (10.173.161.134) with Microsoft SMTP Server (TLS) id 15.1.523.9 via Frontend Transport; Thu, 7 Jul 2016 21:38:11 +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 u67LQ4tQ027640; Thu, 7 Jul 2016 17:38:11 -0400 Received: from plswe13m08.ad.sprint.com (plswe13m08.corp.sprint.com [144.229.214.27]) by preapdm2.corp.sprint.com with ESMTP id 241vtts0dm-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 07 Jul 2016 17:38:11 -0400 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 7 Jul 2016 16:38:09 -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.1178.000; Thu, 7 Jul 2016 16:38:09 -0500 From: "Gorman, Pierce A [CTO]" To: "Peterson, Jon" , Steve Donovan , "modern@ietf.org" Thread-Topic: [Modern] Review of draft-ietf-modern-problem-framework-00.txt Thread-Index: AQHRzk2U1S3ChqfLdUehwOlnB0jAB6ANooUA//+2tyCAAIKuAP//rLGw Date: Thu, 7 Jul 2016 21:38:09 +0000 Message-ID: <14fce615e6d340c49ae8ac4035f97e97@PLSWE13M08.ad.sprint.com> References: <8caed92a03be4425ae31261887b475b7@PLSWE13M08.ad.sprint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.44] Content-Type: multipart/alternative; boundary="_000_14fce615e6d340c49ae8ac4035f97e97PLSWE13M08adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.32.81; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(7916002)(2980300002)(438002)(189002)(377454003)(199003)(586003)(93886004)(106466001)(106116001)(2501003)(108616004)(11100500001)(19625215002)(8936002)(68736007)(7846002)(8676002)(81166006)(81156014)(19580395003)(19300405004)(230783001)(3846002)(30436002)(790700001)(24736003)(87936001)(102836003)(6116002)(260700001)(2906002)(16236675004)(97736004)(15975445007)(4546004)(107886002)(2950100001)(512954002)(2900100001)(551544002)(6806005)(189998001)(5003600100003)(92566002)(5001770100001)(54356999)(356003)(19580405001)(86362001)(7696003)(5250100002)(7736002)(50986999)(76176999)(33646002)(84326002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB042; H:preapdm2.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD038; 1:W/+AeUI6y/lFTisGK+WySAvUQ5jo+IF1TdRRY4KuZXHQ5kTZAfcFpaXU5xDdWKL3Z+bmTyxEgM9xFW0ayjweB5Ifd2k2R68rdE7OoWChF9uzAPUgfAVSu+0e2XFNqFux7x2ZV5gR7fsWwE+bp9aZyMr3cvFAcxMZfEu+N6+nYWdbyGIRedpJ+It+RnDlZ/SHV0Eo2WjjR9bIRVnhgkwIfjyYan8N2mKVVf9Vxj7BpZugw5g9skIiJVuVovBOiixtMa/OJ+6vienM6XhkBoi5aKK/+5B2Czh6wRXjmLPfP4R6eVHyj4BSBlbRhO9gwP8EJMC6F7DhdvL/BEWPg1ak7RgRDJASBGQVE9f5V6DBIVPwFO2wjxV+5tJYIzuys4GQQVWlO9Yve5XoW1koQ2Nj/x4kjzb3Jhe5jAajoxkAUAKV6/TMmQUGq08aqn8B6tpT5xKyOI0XleLYZuEC89NM+lIfDCZIrKatIj1mIEyEjj7sK4b0MSBBaZTAY7xkzDSNrcTmE79DRP3CN6nHSNCIJ/V8vv2HwzZ1orEve+Glcbo2wJcAUt1fOvcglHZ/rplC X-MS-Office365-Filtering-Correlation-Id: b0bda927-a5f0-49c2-c64a-08d3a6aefeb6 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB042; 2:Hjmi6yi1nzr233sFOmEu1G1PddNWwJbYsp4SplLwAungnAMmr5rtm6tgdzgZpZ2eqENa6Ql7ZzMWbya9fndVJBLR9FqehlfNrBY1fZLFqxx8D2k2dq/4isA0nQ5PfETWU58a/RK9yR6rhvZXaFI+8mvWu8M1WUd6Zj8Pewzd83h5otZG7nDI+DlD93T5+mYq; 3:8ieAs2Eou06YH6vhce9PBlxohfdekwW9JSh7g89iA8P2/5aFjl+YFGjB/p4JvJNvM5P0R1n/KNMXBFZQ8g2HOyM9O/KL8CBdq68IlVA4PXO9XIqGNzQMB2Q4wKqwPy+N/Q6FQBYF8gsdm4Cokvtiu3l9dCgBkQh1AXYK+0zcZfZ3cVRMyPnTwO4vu5txjue8+cHsTQCCuG+o8Ub45cmfMvq0iEOb1yDSVRJnb7t5dfVgO3hQo0SZAJYxCampsFhv3NUmAzxvn5/Q34qCAhJN2g==; 25:LL0ClmhxktKmoWQJSM4RgOFBTUbdGBURFUbURANITh5LlgX3PBx+BlTOADGw8ApMrfRG4XDkMka6B2LQH51Fcob1ia2Hp68YteGybNXAwxq/DuQ6Jiiz454/DZTQ/JmVYZ54UMC13RI/85bwiYuy2tZwNCSYqo5/l1Uy1W9kqsLFqeKKDNpmZKNCLr1zXwfp2wbPUHKu6IkxXayq/lu5q24eu/s8jrq4h7i2QUIX+e9FlCOxBPU3hA5qF/4Tv45fBVD3QGO8Z2v9j/6zf0z3cSNqr/2UyX2N5bxcdk6N0ugVNsTYR+RbytKrxKvS8IJRzVOyIep6/i0VUIjCXE7MKPgdAose5kpWKJOWNdB0UCs9XnmSvP4ehhn3OT3uDtnN5D/vd3q6AVY4xd4O2jn7uaHfzsFxa0KYbcWGMMyZKGHq4y3Z46v1eORCM2HF2h7g X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BL2FFO11HUB042; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB042; 20:s6E1adXLxAvls6scLwgQZ4hRVWWiUl28s9XC19Y33xNgQIfmbY/UroNkrJ1lEy1DMa8BNvHSmiZYxk7WsWNsBbyeh62ZVXsud/Uf4YiHUKCJY59SV69OyyvO26NZIGk8iFJDI3ExXSeOHWNtK3FsGO0rjPOn7iYCFg+3DbyqUqfCRPwX2mjknrzHSTjskm92Djf1RFyiGpE7nGGjX0t1CMWt8YgcjHo4NB65PesburHBBJZ9q6ywge4WU3I+BjxcrY2/dkuQWMgA5UNTz44UTYb9Gy25jATnzso3kVcDbOIsKGzC1zTi2rX7UyTII5RdhgjGr3Jwf9GIeDtKmKygdAgBgaDHr0DRMS3MxD6VUTRCMulI7/u6QMMW+iOaA9naVkPfyf2fYkAYh/Vhr8IzUjLLPNwiofh9P1DAJoyq7LE= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(18430343700868)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13024025)(13018025)(13015025)(13023025)(13017025)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BL2FFO11HUB042; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB042; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB042; 4:V0WxJKp7oZnsZmAQL+w7CecWR30DuUfmivdKd1BWEYAwAhoLLoK7wNC3kO6cihXOYXFPM8xbI4GtCZLSWJWZw/GcFEI+WGoxYX7yqxQO4AVVtqQsBoKAkyhIOfCb2ll/IPGOZdAAbo0nryiQdhhYy15PmU94R680ihPfRZISWRejItFo9ioLzx3AWorKTyRSz4I81UlYFGBgpQtqDf0mLNxTohamkcgKblkfvVWMNaFMgYq6dkikODEVaNx1OGt1zSLuqHNHVbEq/FV4uu9+rhlAJluUF7SAQ+Fg1gGvy9vYzGTCJ7r/2+S7+chOFafvCk0gwWjzU4GLlT8NJgkGXWJtMewDatPm8ToFM927nUNRQJ6DJ0R61tL1JW3MWBCTOkp+aDSHVSF55XSvVgpOivvNzVf3U4+VQckqutsMwfLFKEED1P4yBgyykUEfJ8/CGA5y99Lylt3beLGdlDBnQbWV2z3K0tSCPzeqpvQIe/+36Rv2o8kyn56Igzn83aEugvxiNSJ74ni264IB0nlqv1HusHLB0JCfOX8Xr1FEfGm7bbQpYlEdvXzMFiOECS0h+SF9o+06/JDopXvfKlvyMA== X-Forefront-PRVS: 0996D1900D X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2FFO11HUB042; 23:wEhsPuhQ12ffn8P2OVJCMfGhljM1RzDWln47pmyh?= =?us-ascii?Q?2YRRL9nPyLT/JLwqCaixivR+WxBOYOdJnwL81GnvEpsuFOWtxR+cXksQrPOS?= =?us-ascii?Q?f6I/WLfKKp60sasvEHZ5w5pD23FCPK0lNTe5ShdCrLlkqvKFfWInXFfVEY+N?= =?us-ascii?Q?PDLNmpHr1U0bT8MLFKLzKs+yXXtiKaUIblZKRaAZ3Fja9Q31NpYdjYc7ExoD?= =?us-ascii?Q?isVd5tl+y24Syjpe9aTiOEWDpi6fefRjrZgauy40N+EcZaf9liCe9OVRRWzF?= =?us-ascii?Q?m1Hasq8UwV0hFE6+pBnEw7FLh5eYfho1NEIIZLPu1F33d/nDC1s44HlmvntJ?= =?us-ascii?Q?2af6+zDGBatnvsxGj4pH/HgAM4EM94HqQ5OfTKZ8C789YDUCgaCFVQPG8MTg?= =?us-ascii?Q?H/kU91XsCD6jVgeb1EZMujS3+3vq8i3EHTix+JKUaBiJSveIcfZPX/N82bLR?= =?us-ascii?Q?ZlO/y1sUW1Dht2xlQtzsNonGklWkM0+YUpe/UNyPG3fgUyWrcWt7BA4sKAID?= =?us-ascii?Q?/n28VhvPbDHfbflEz4w4p71HyyRXSnkJBaxgIvHu4RAHtqB0e5+HFoSUOlNF?= =?us-ascii?Q?b0AfXoa3oKAdiSaq563Rm2/ApkW9vBwCBaSxs0fINmc1g7gx7+UTOh9AR96T?= =?us-ascii?Q?5BDq2ayHMnlE4y0rEi4ql6gk6OPfk8JtSTDcmm6rmgjCTEOj5AinCSPxyfqS?= =?us-ascii?Q?X4FNQJreNZd5IhG1jhSrxDqf0HxgSs6aObuHfvCCkFPBx2FuIPWpI641aSbv?= =?us-ascii?Q?BMHUdPG8x8r1t960YpDADjKZ7x3IvO4nKvV5BvgTtw87SWTLawqGvjKdDMXm?= =?us-ascii?Q?wi05m5jDrUSsRiuusNc3lnYDjE/AsySeQ2zl6TCepC9N4r34MT/ORIp+urV8?= =?us-ascii?Q?m6pa9ix7ork0SDDwyK9tA0vTmZczyHtjH8yzTK8hQpU0mJC1JpgtXEVGnNGj?= =?us-ascii?Q?2quRKt6Qm+38H+mHMMvokIPSslTTsqfwMHwkhI+aDZykqgOfj7VY3vn03s5o?= =?us-ascii?Q?UeyfhX9ysNWyotxkmLu4XNfyyfn803vVXBQw65K83D0oQjCpUL04IBnIMzm0?= =?us-ascii?Q?Yk083HhRL/RUt8qmizNJ5cznfVHOY5ymDAChuE73W1bCg2OaJNlYEkO3/Dt+?= =?us-ascii?Q?DgzFIx1eT1bqSG8R6Zix76zEAKvcRBugeR/FlBar7ZzzyuP1vOSL870Y0Iqx?= =?us-ascii?Q?s4qXwNQeHjRwVUk1v0XX4ffvBKz13xoRI+12EO1nR31mgxIe1q8y/Pt+CfOx?= =?us-ascii?Q?KFJ2kqdCoCaB7a8IzSxuqSSF8X0FBzbjFdTVCP8yPdUT75NO6Q2POLlnSRUJ?= =?us-ascii?Q?SfVNt+BPbqmbJMkzRxXb2N6Xb7KP2p9601cUFk3l8GizKw3jEpjVDfSrRUcU?= =?us-ascii?Q?GCb8RI6GFpo4lB2F6EAf6SGIwjBwQjQSuyPg+wwMbweUricLbuw4UmMQqhSA?= =?us-ascii?Q?s8aqVk1PTA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB042; 6:3gylKzrq3lXON7fXXrbNbl0ixGR9NaTLSxnBT5+swptBbHQ6hZg0bnZZ+umQE70sGp+sBTrNk89eFUFrZ0wGx/5CJf4ohN173r5m2V65cdnF0RW8ozIXfKVAsN44d+69vgUjRoUK1LXKidKyr3i58Mm/wmeBC6lkdPja3rNV27xD0WIwf6ZxfMivlg1X+5m4O7Hu2XxNHZhKwhm+U3rKIcZeFb2luQOaX4Bx49S5J4m7KYxKiUfyn6+VfgLqp8+AByemN5Enw9SSo8NhE6E2EWJaOx7gK2qyXDlY/iuXjDObg3dFC9Ln4/7AugfxovY4Zlup182/0S+kw7srPB+oDfgz49VbXouijbwEifA5yMA=; 5:eZ11deBV9ZAr2EeZHmWjy2pmpF6cLki3w1pzLOfqdibyoDOCeLLddVMnAXNN83dAMF3aqd+tqZyXd+X8267lGmasCGbtqBinQUTZ3cWbQRjyhwPNglLW/aOcsqeb8pJoxrKtiwtVARuj0Os/HpvqRg==; 24:1lSOnojDEe6y2gdSAGZcwPDitn8AwRFSY3l3H0Ld5jvPFFIDkh6JdU7uJF1Phm3AGMd+hEyRjL847hUSJqSLZGY3pSpZXwgTsXkvyl+vhys=; 7:TUHvpLLSFikJ0mASkdx2V45vK8rIMT1tapVAlUryu8DI+tFRwtkV8m9K2HveJqLvPsh9SRWOI2DMnl7CT7ktI1I8qQ55YKfmG+jvSUZexYtRwDHy49Z7skRUut3Vqz8fHfJ7CQ0YDG35Tbh7sDvlmKPtDv6MQSgXE7pRamcS1gd5t3odlWDDhnd9tgfQOHNHjeyjbi2ERI4/We71MvXR2dSTytkKyNiYkQ99r1bqRulM7EpF3Th3l2CeSh2ujB3+ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jul 2016 21:38:11.6659 (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: BL2FFO11HUB042 Archived-At: Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-00.txt X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Managing, 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, 07 Jul 2016 21:38:17 -0000 --_000_14fce615e6d340c49ae8ac4035f97e97PLSWE13M08adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You may be right. I may be (just as) guilty of solution jumping. I don't agree though that suggesting the use of standard security architect= ural approaches (i.e., multi-factor authentication) to inter-system (or int= er-personal) communications requirements with respect to managing CRI is a = focus "on a narrow way of implementing this". A problem statement should state a problem. For example: Until user-level Communications Reachability Information (CRI) is modeled t= o include multiple factors of authenticity instead of a single factor (i.e.= , the "telephone number"), robo-calling and robo-texting will continue to b= e problems plaguing the global telecommunications infrastucture and it's us= ers. If we want the telephone network to be better at screening calls for users,= we need to provide more information to the network (and/or the user) to im= prove filtering. Authenticating calling numbers will be of very limited us= efulness as an anti-robo-calling filter. Including a password in a SIP URI = is trivial. Associating and storing credentials with a telephone number is= less so, but would be extremely useful as SPAM filters. MODERN shouldn't manage telephone numbers. MODERN should manage CRI. CRI = could include telephone numbers, e-mail and social application addresses, c= redentials for managing access to CRI data, and credentials used in signali= ng which assist in authenticating and filtering communications attempts. Pierce From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: July 07, 2016 3:59 PM To: Gorman, Pierce A [CTO] ; Steve Donovan ; modern@ietf.org Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-00.txt I think the only reason your idea here is being "cheerfully discarded," as = you put it, is that we're just not on the same page about what is an archit= ecture, versus a framework, versus a solution. What you're describing goes = beyond a problem statement, beyond even proposing an architecture or protoc= ol solution - it sketches an actual implementation that someone could offer= as a commercial product. We don't make those at the IETF. The irony in this misalignment of our understanding of working group's job = is that the MODERN charter is probably compatible with what you're proposin= g, as far as I can tell. A .name namespace allocated for this purpose of ex= posing reachability information would be an implementation of the "retrieva= l interface" component of the MODERN framework described in the problem sta= tement. The question of what "factors" you include in a query to the retrie= val interface is indeed one of the big ones we're interested in exploring -= we hope to eventually produce an information model that will capture what = those factors would be. We want to create an information model versatile en= ough to work with a number of distinct bindings (that is, protocols that mi= ght carry the query). But retrieval is only one component of the framework = we're developing, as we're also concerned with how identifiers get allocate= d (maybe how those .name domains get assigned?) and what information gets p= rovisioned against them (maybe what provisioning occurs so that your "facto= rs" help you get the reachability information you need?). So again, it's not that I'm even necessarily opposed to what you're proposi= ng, you're just not looking at the same parts of the problem that I am, and= you're apparently focused on a narrow way of implementing this. Implementi= ng will be the easy part. Getting the information model right is hard, and = that's the work we're chartered to do. Jon Peterson Neustar, Inc. From: "Gorman, Pierce A [CTO]" > Date: Thursday, July 7, 2016 at 11:38 AM To: Jon Peterson = >, Steve Donovan = >, "modern@ietf.org" > Subject: RE: [Modern] Review of draft-ietf-modern-problem-framework-00.txt I haven't read the most current version, but I think it's fair to say I've = provided most of the public non-political feedback to MODERN so far. The last comments I made advocated for the use of .name. domain name space = (or a new name space) tied to telephone numbers with the concept of MODERN = hosting Communications Reachability Information (CRI) and that index keys i= nto a CRI database could be passwords which could also be telephone numbers= . The idea was cheerfully disregarded but I will bring it up again. The MODE= RN "problem statement" is a solution architecture (not a problem statement)= , and it's inadequate, and centric to NANP telephony considerations. If you want a globally usable telephone number routing information model fo= r IP-based telecommunications and you want to more usefully solve problems = like calling identity authentication (globally) and non-geographic number p= ortability (for NANP), you should seriously be looking at multi-factor auth= entication for routing information queries. Factors such as who do you thi= nk you're calling? And, what is the number [password] you think is associat= ed with them? You send a query to the CRI and you only know one factor (e.g., telephone n= umber)? That provides you an index into the least useful telecommunication= s information. Perhaps only a telephone number into a SPAM-only voicemail = box or voice-to-text-to-SPAM-text-box or whatever the user has defined that= protects them from unauthorized and unauthenticated communications attempt= s. Create a multi-factor communications model (which SIP and other communi= cations protocols easily and commonly support) and you can have a meaninful= impact on global robo-calling and robo-texting SPAM. I have 3 main telephone numbers that are unique to me. Very few people hav= e all 3. I compartmentalize my communications based on whether they are pr= ivate, family, or business. I could easily want or have more. Many people= do. Very few people purposefully distribute all of their telephone number= s, e-mail addresses, social network personas, et cetera to all of their pri= vate, family, and work contacts. If you want to give users globally, the world over, control over CRI, build= a model that addresses their communications reachability needs, not their = voice telephony needs. Regards, Pierce From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: July 07, 2016 12:33 PM To: Steve Donovan >; modern@ietf.org Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-00.txt Thanks Steve, I cleaned these up. Jon Peterson Neustar, Inc. From: Modern > on b= ehalf of Steve Donovan > Date: Friday, June 24, 2016 at 12:21 PM To: "modern@ietf.org" > Subject: [Modern] Review of draft-ietf-modern-problem-framework-00.txt I have reviewed draft-ietf-modern-problem-framework-00.txt. This document = is in great shape and I only have editorial comments as follows. Regards, Steve ----- Section 1: s /familiar from the/familiar to the/ s/ manenr/manner/ s/evolvling/evolving/ Section 2.1 s/assginees/assignees/ s/entitiy/entity/ Section 3 Need references for DRINKS and WEIRDS Section 4.1.4 s/Aquiring/Acquiring/ Section 4.1.5 s/wtih/with/ Section 4.2.1.2 s/Regisrar/Registrar/ Section 4.1.2.3 s/could could/could/ Section 4.3.2 s/to access to this/to access this/ ________________________________ 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_14fce615e6d340c49ae8ac4035f97e97PLSWE13M08adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You may be right.  I may be (just = as) guilty of solution jumping.

 

I don’t agree though that suggest= ing the use of standard security architectural approaches (i.e., multi-fact= or authentication) to inter-system (or inter-personal) communications requirements with respect to managing CRI is a focus “= ;on a narrow way of implementing this”.

 

A problem statement should state a prob= lem.

 

For example:

 

Until user-l= evel Communications Reachability Information (CRI) is modeled to include mu= ltiple factors of authenticity instead of a single factor (i.e., the “telephone number”), robo-calling and robo-t= exting will continue to be problems plaguing the global telecommunications = infrastucture and it’s users.

 

If we want the telephone network to be = better at screening calls for users, we need to provide more information to= the network (and/or the user) to improve filtering.  Authenticating calling numbers will be of very limited usefulness as an an= ti-robo-calling filter. Including a password in a SIP URI is trivial. = Associating and storing credentials with a telephone number is less so, bu= t would be extremely useful as SPAM filters.

 

MODERN shouldn’t manage telephone= numbers.  MODERN should manage CRI.  CRI could include telephone= numbers, e-mail and social application addresses, credentials for managing access to CRI data, and credentials used in signaling which a= ssist in authenticating and filtering communications attempts.

 

Pierce

 

From:= Peterson, Jon [mailto:jon.peterson@neusta= r.biz]
Sent: July 07, 2016 3:59 PM
To: Gorman, Pierce A [CTO] <Pierce.Gorman@sprint.com>; Steve D= onovan <srdonovan@usdonovans.com>; modern@ietf.org
Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-= 00.txt

 

&n= bsp;

I think= the only reason your idea here is being "cheerfully discarded," = as you put it, is that we're just not on the same page about what is an arc= hitecture, versus a framework, versus a solution. What you're describing goes beyond a problem statement, beyond even propos= ing an architecture or protocol solution - it sketches an actual implementa= tion that someone could offer as a commercial product. We don't make those = at the IETF.

&n= bsp;

The iro= ny in this misalignment of our understanding of working group's job is that= the MODERN charter is probably compatible with what you're proposing, as f= ar as I can tell. A .name namespace allocated for this purpose of exposing reachability information would be a= n implementation of the "retrieval interface" component of the MO= DERN framework described in the problem statement. The question of what &qu= ot;factors" you include in a query to the retrieval interface is indeed one of the big ones we're interested in exploring - we= hope to eventually produce an information model that will capture what tho= se factors would be. We want to create an information model versatile enoug= h to work with a number of distinct bindings (that is, protocols that might carry the query). But retrieval is= only one component of the framework we're developing, as we're also concer= ned with how identifiers get allocated (maybe how those .name domains get a= ssigned?) and what information gets provisioned against them (maybe what provisioning occurs so that your &quo= t;factors" help you get the reachability information you need?).<= /o:p>

&n= bsp;

So agai= n, it's not that I'm even necessarily opposed to what you're proposing, you= 're just not looking at the same parts of the problem that I am, and you're= apparently focused on a narrow way of implementing this. Implementing will be the easy part. Getting the info= rmation model right is hard, and that's the work we're chartered to do.

&n= bsp;

Jon Pet= erson

Neustar= , Inc.

&n= bsp;

From= : "Gorman, Pie= rce A [CTO]" <Pierce.Go= rman@sprint.com>
Date: Thursday, July 7, 2016 at 11:38 AM
To: Jon Peterson <jon= .peterson@neustar.biz>, Steve Donovan <srdonovan@usdonovans.com>, "modern@ietf.org" <modern@ietf.org>
Subject: RE: [Modern] Review of draft-ietf-modern-problem-framework-= 00.txt

&n= bsp;

I haven’t read the most current v= ersion, but I think it’s fair to say I’ve provided most of the = public non-political feedback to MODERN so far.

 

The last comments I made advocated for = the use of .name. domain name space (or a new name space) tied to telephone= numbers with the concept of MODERN hosting Communications Reachability Information (CRI) and that index keys into a CRI database cou= ld be passwords which could also be telephone numbers.

 

The idea was cheerfully disregarded but= I will bring it up again.  The MODERN “problem statement”= is a solution architecture (not a problem statement), and it’s inadequate, and centric to NANP telephony considerations.

 

If you want a globally usable telephone= number routing information model for IP-based telecommunications and you w= ant to more usefully solve problems like calling identity authentication (globally) and non-geographic number portability (= for NANP), you should seriously be looking at multi-factor authentication f= or routing information queries.  Factors such as who do you think you&= #8217;re calling? And, what is the number [password] you think is associated with them?=

 

You send a query to the CRI and you onl= y know one factor (e.g., telephone number)?  That provides you an inde= x into the least useful telecommunications information.  Perhaps only a telephone number into a SPAM-only voicemail box or voice-to= -text-to-SPAM-text-box or whatever the user has defined that protects them = from unauthorized and unauthenticated communications attempts.  Create= a multi-factor communications model (which SIP and other communications protocols easily and commonly support)= and you can have a meaninful impact on global robo-calling and robo-textin= g SPAM.

 

I have 3 main telephone numbers that ar= e unique to me.  Very few people have all 3.  I compartmentalize = my communications based on whether they are private, family, or business.  I could easily want or have more.  Many people do.=   Very few people purposefully distribute all of their telephone numbe= rs, e-mail addresses, social network personas, et cetera to all of their pr= ivate, family, and work contacts.

 

If you want to give users globally, the= world over, control over CRI, build a model that addresses their communica= tions reachability needs, not their voice telephony needs.

 

Regards,

 

Pierce

 

From= : Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: July 07, 2016 12:33 PM
To: Steve Donovan <sr= donovan@usdonovans.com>; modern@ietf.org
Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-= 00.txt

 =

 <= /span>

Thanks = Steve, I cleaned these up.

 <= /span>

Jon Pet= erson

Neustar= , Inc.

 <= /span>

From= : Modern <modern-bounces@ietf.org> on beh= alf of Steve Donovan <srdono= van@usdonovans.com>
Date: Friday, June 24, 2016 at 12:21 PM
To: "modern@ietf.org&quo= t; <modern@ietf.org>
Subject: [Modern] Review of draft-ietf-modern-problem-framework-00.t= xt

 <= /span>

I have = reviewed draft-ietf-modern-problem-framework-00.txt.  This document is in = great shape and I only have editorial comments as follows.

Regards,

Steve

-----

Section 1:

s /familiar from the/familiar to the/
s/ manenr/manner/
s/evolvling/evolving/

Section 2.1
s/assginees/assignees/
s/entitiy/entity/

Section 3
Need references for DRINKS and WEIRDS

Section 4.1.4
s/Aquiring/Acquiring/

Section 4.1.5
s/wtih/with/

Section 4.2.1.2
s/Regisrar/Registrar/

Section 4.1.2.3
s/could could/could/

Section 4.3.2
s/to access to this/to access this/


&n= bsp;


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_14fce615e6d340c49ae8ac4035f97e97PLSWE13M08adsprintcom_-- From nobody Thu Jul 7 14:50:30 2016 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E3412D8CC for ; Thu, 7 Jul 2016 14:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 MCfn9wg6BVcb for ; Thu, 7 Jul 2016 14:50:24 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 190B212D532 for ; Thu, 7 Jul 2016 14:50:24 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u67LhbLJ028819; Thu, 7 Jul 2016 17:50:23 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 23x8dh4sh8-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 07 Jul 2016 17:50:22 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 7 Jul 2016 17:50:22 -0400 From: "Peterson, Jon" To: "Gorman, Pierce A [CTO]" , Steve Donovan , "modern@ietf.org" Thread-Topic: [Modern] Review of draft-ietf-modern-problem-framework-00.txt Thread-Index: AQHRzk2W0VnsFaP+xEeTcvTqXwlhyKANHGCAgACHgQD//7HpgIAAgF6A//+ODAA= Date: Thu, 7 Jul 2016 21:50:21 +0000 Message-ID: References: <8caed92a03be4425ae31261887b475b7@PLSWE13M08.ad.sprint.com> <14fce615e6d340c49ae8ac4035f97e97@PLSWE13M08.ad.sprint.com> In-Reply-To: <14fce615e6d340c49ae8ac4035f97e97@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.6.3.160329 x-originating-ip: [10.96.12.185] Content-Type: multipart/alternative; boundary="_000_D3A41A431A5135jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-07_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607070200 Archived-At: Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-00.txt X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Managing, 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, 07 Jul 2016 21:50:27 -0000 --_000_D3A41A431A5135jonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The question of whether you require multi-factor authentication to access r= eachability information or not is, actually, a very narrow implementation d= etail. There will of course be security requirements on accessing and chang= ing the data that our information model captures, and it could be that thos= e requirements will entail that multi-factor authorization is required - th= ough that the term "multi-factor authentication" also has a specific connot= ation in security design that might be a little different than what you mea= n here. But again - the bulk of our chartered work in MODERN is just figuri= ng out what that information model is. You're worrying about things that we= won't even get to until we've gone through much of that process. And while your problem statement below does state a specific problem, that = problem as stated doesn't happen to be the problem this group is chartered = to solve. Again, this group is much more concerned with the broader questio= n of how and why you might populate data associated with telephone numbers = for a variety of applications than with meeting any tactical industry goal = like reducing unwanted communications. Reducing unwanted communications cou= ld certainly be a very desirable side effect of some of the information mod= els we'd consider here, but that problem didn't motivate this working group= . I'm sure we don't need another history lesson, but this working group has= more to do with an IP transition of telephony in general than with any spe= cific ill we imagine that IP transition might exacerbate. Jon Peterson Neustar, Inc. From: "Gorman, Pierce A [CTO]" > Date: Thursday, July 7, 2016 at 2:38 PM To: Jon Peterson = >, Steve Donovan = >, "modern@ietf.org" > Subject: RE: [Modern] Review of draft-ietf-modern-problem-framework-00.txt You may be right. I may be (just as) guilty of solution jumping. I don=92t agree though that suggesting the use of standard security archite= ctural approaches (i.e., multi-factor authentication) to inter-system (or i= nter-personal) communications requirements with respect to managing CRI is = a focus =93on a narrow way of implementing this=94. A problem statement should state a problem. For example: Until user-level Communications Reachability Information (CRI) is modeled t= o include multiple factors of authenticity instead of a single factor (i.e.= , the =93telephone number=94), robo-calling and robo-texting will continue = to be problems plaguing the global telecommunications infrastucture and it= =92s users. If we want the telephone network to be better at screening calls for users,= we need to provide more information to the network (and/or the user) to im= prove filtering. Authenticating calling numbers will be of very limited us= efulness as an anti-robo-calling filter. Including a password in a SIP URI = is trivial. Associating and storing credentials with a telephone number is= less so, but would be extremely useful as SPAM filters. MODERN shouldn=92t manage telephone numbers. MODERN should manage CRI. CR= I could include telephone numbers, e-mail and social application addresses,= credentials for managing access to CRI data, and credentials used in signa= ling which assist in authenticating and filtering communications attempts. Pierce From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: July 07, 2016 3:59 PM To: Gorman, Pierce A [CTO] >; Steve Donovan >; modern@ietf.org Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-00.txt I think the only reason your idea here is being "cheerfully discarded," as = you put it, is that we're just not on the same page about what is an archit= ecture, versus a framework, versus a solution. What you're describing goes = beyond a problem statement, beyond even proposing an architecture or protoc= ol solution - it sketches an actual implementation that someone could offer= as a commercial product. We don't make those at the IETF. The irony in this misalignment of our understanding of working group's job = is that the MODERN charter is probably compatible with what you're proposin= g, as far as I can tell. A .name namespace allocated for this purpose of ex= posing reachability information would be an implementation of the "retrieva= l interface" component of the MODERN framework described in the problem sta= tement. The question of what "factors" you include in a query to the retrie= val interface is indeed one of the big ones we're interested in exploring -= we hope to eventually produce an information model that will capture what = those factors would be. We want to create an information model versatile en= ough to work with a number of distinct bindings (that is, protocols that mi= ght carry the query). But retrieval is only one component of the framework = we're developing, as we're also concerned with how identifiers get allocate= d (maybe how those .name domains get assigned?) and what information gets p= rovisioned against them (maybe what provisioning occurs so that your "facto= rs" help you get the reachability information you need?). So again, it's not that I'm even necessarily opposed to what you're proposi= ng, you're just not looking at the same parts of the problem that I am, and= you're apparently focused on a narrow way of implementing this. Implementi= ng will be the easy part. Getting the information model right is hard, and = that's the work we're chartered to do. Jon Peterson Neustar, Inc. From: "Gorman, Pierce A [CTO]" > Date: Thursday, July 7, 2016 at 11:38 AM To: Jon Peterson = >, Steve Donovan = >, "modern@ietf.org" > Subject: RE: [Modern] Review of draft-ietf-modern-problem-framework-00.txt I haven=92t read the most current version, but I think it=92s fair to say I= =92ve provided most of the public non-political feedback to MODERN so far. The last comments I made advocated for the use of .name. domain name space = (or a new name space) tied to telephone numbers with the concept of MODERN = hosting Communications Reachability Information (CRI) and that index keys i= nto a CRI database could be passwords which could also be telephone numbers= . The idea was cheerfully disregarded but I will bring it up again. The MODE= RN =93problem statement=94 is a solution architecture (not a problem statem= ent), and it=92s inadequate, and centric to NANP telephony considerations. If you want a globally usable telephone number routing information model fo= r IP-based telecommunications and you want to more usefully solve problems = like calling identity authentication (globally) and non-geographic number p= ortability (for NANP), you should seriously be looking at multi-factor auth= entication for routing information queries. Factors such as who do you thi= nk you=92re calling? And, what is the number [password] you think is associ= ated with them? You send a query to the CRI and you only know one factor (e.g., telephone n= umber)? That provides you an index into the least useful telecommunication= s information. Perhaps only a telephone number into a SPAM-only voicemail = box or voice-to-text-to-SPAM-text-box or whatever the user has defined that= protects them from unauthorized and unauthenticated communications attempt= s. Create a multi-factor communications model (which SIP and other communi= cations protocols easily and commonly support) and you can have a meaninful= impact on global robo-calling and robo-texting SPAM. I have 3 main telephone numbers that are unique to me. Very few people hav= e all 3. I compartmentalize my communications based on whether they are pr= ivate, family, or business. I could easily want or have more. Many people= do. Very few people purposefully distribute all of their telephone number= s, e-mail addresses, social network personas, et cetera to all of their pri= vate, family, and work contacts. If you want to give users globally, the world over, control over CRI, build= a model that addresses their communications reachability needs, not their = voice telephony needs. Regards, Pierce From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: July 07, 2016 12:33 PM To: Steve Donovan >; modern@ietf.org Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-00.txt Thanks Steve, I cleaned these up. Jon Peterson Neustar, Inc. From: Modern > on b= ehalf of Steve Donovan > Date: Friday, June 24, 2016 at 12:21 PM To: "modern@ietf.org" > Subject: [Modern] Review of draft-ietf-modern-problem-framework-00.txt I have reviewed draft-ietf-modern-problem-framework-00.txt. This document = is in great shape and I only have editorial comments as follows. Regards, Steve ----- Section 1: s /familiar from the/familiar to the/ s/ manenr/manner/ s/evolvling/evolving/ Section 2.1 s/assginees/assignees/ s/entitiy/entity/ Section 3 Need references for DRINKS and WEIRDS Section 4.1.4 s/Aquiring/Acquiring/ Section 4.1.5 s/wtih/with/ Section 4.2.1.2 s/Regisrar/Registrar/ Section 4.1.2.3 s/could could/could/ Section 4.3.2 s/to access to this/to access this/ ________________________________ 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_D3A41A431A5135jonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <33550EA554004147AA3BFE07799CA97C@neustar.biz> Content-Transfer-Encoding: quoted-printable

The question of whether you require multi-factor authentication to acc= ess reachability information or not is, actually, a very narrow implementat= ion detail. There will of course be security requirements on accessing and = changing the data that our information model captures, and it could be that those requirements will entail that m= ulti-factor authorization is required - though that the term "multi-fa= ctor authentication" also has a specific connotation in security desig= n that might be a little different than what you mean here. But again - the bulk of our chartered work in MODERN is jus= t figuring out what that information model is. You're worrying about things= that we won't even get to until we've gone through much of that process.

And while your problem statement below does state a specific problem, = that problem as stated doesn't happen to be the problem this group is chart= ered to solve. Again, this group is much more concerned with the broader qu= estion of how and why you might populate data associated with telephone numbers for a variety of applicati= ons than with meeting any tactical industry goal like reducing unwanted com= munications. Reducing unwanted communications could certainly be a very des= irable side effect of some of the information models we'd consider here, but that problem didn't motivate th= is working group. I'm sure we don't need another history lesson, but this w= orking group has more to do with an IP transition of telephony in general t= han with any specific ill we imagine that IP transition might exacerbate. 

Jon Peterson
Neustar, Inc.

From: "Gorman, Pierce A [CTO]&= quot; <Pierce.Gorman@sprint.= com>
Date: Thursday, July 7, 2016 at 2:3= 8 PM
To: Jon Peterson <jon.peterson@neustar.biz>, Steve Donov= an <srdonovan@usdonovans.com= >, "modern@ietf.org"= ; <modern@ietf.org>
Subject: RE: [Modern] Review of dra= ft-ietf-modern-problem-framework-00.txt

You may be right.  I may be (just = as) guilty of solution jumping.

 

I don=92t agree though that suggesting = the use of standard security architectural approaches (i.e., multi-factor a= uthentication) to inter-system (or inter-personal) communications requirements with respect to managing CRI is a focus =93on = a narrow way of implementing this=94.

 

A problem statement should state a prob= lem.

 

For example:

 

Until user-l= evel Communications Reachability Information (CRI) is modeled to include mu= ltiple factors of authenticity instead of a single factor (i.e., the =93telephone number=94), robo-calling and robo-texting w= ill continue to be problems plaguing the global telecommunications infrastu= cture and it=92s users.

 

If we want the telephone network to be = better at screening calls for users, we need to provide more information to= the network (and/or the user) to improve filtering.  Authenticating calling numbers will be of very limited usefulness as an an= ti-robo-calling filter. Including a password in a SIP URI is trivial. = Associating and storing credentials with a telephone number is less so, bu= t would be extremely useful as SPAM filters.

 

MODERN shouldn=92t manage telephone num= bers.  MODERN should manage CRI.  CRI could include telephone num= bers, e-mail and social application addresses, credentials for managing access to CRI data, and credentials used in signaling which a= ssist in authenticating and filtering communications attempts.

 

Pierce

 

From:= Peterson, Jon [mailto:jon.peterson@neustar.biz]
Sent: July 07, 2016 3:59 PM
To: Gorman, Pierce A [CTO] <Pierce.Gorman@sprint.com>; Steve Donovan <srdonovan@usdonovans.com>; modern@ietf.org
Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-= 00.txt

 

&n= bsp;

I think= the only reason your idea here is being "cheerfully discarded," = as you put it, is that we're just not on the same page about what is an arc= hitecture, versus a framework, versus a solution. What you're describing goes beyond a problem statement, beyond even propos= ing an architecture or protocol solution - it sketches an actual implementa= tion that someone could offer as a commercial product. We don't make those = at the IETF.

&n= bsp;

The iro= ny in this misalignment of our understanding of working group's job is that= the MODERN charter is probably compatible with what you're proposing, as f= ar as I can tell. A .name namespace allocated for this purpose of exposing reachability information would be a= n implementation of the "retrieval interface" component of the MO= DERN framework described in the problem statement. The question of what &qu= ot;factors" you include in a query to the retrieval interface is indeed one of the big ones we're interested in exploring - we= hope to eventually produce an information model that will capture what tho= se factors would be. We want to create an information model versatile enoug= h to work with a number of distinct bindings (that is, protocols that might carry the query). But retrieval is= only one component of the framework we're developing, as we're also concer= ned with how identifiers get allocated (maybe how those .name domains get a= ssigned?) and what information gets provisioned against them (maybe what provisioning occurs so that your &quo= t;factors" help you get the reachability information you need?).<= /o:p>

&n= bsp;

So agai= n, it's not that I'm even necessarily opposed to what you're proposing, you= 're just not looking at the same parts of the problem that I am, and you're= apparently focused on a narrow way of implementing this. Implementing will be the easy part. Getting the info= rmation model right is hard, and that's the work we're chartered to do.

&n= bsp;

Jon Pet= erson

Neustar= , Inc.

&n= bsp;

From= : "Gorman, Pie= rce A [CTO]" <Pierce.Go= rman@sprint.com>
Date: Thursday, July 7, 2016 at 11:38 AM
To: Jon Peterson <jon= .peterson@neustar.biz>, Steve Donovan <srdonovan@usdonovans.com>, "modern@ietf.org" <modern@ietf.org>
Subject: RE: [Modern] Review of draft-ietf-modern-problem-framework-= 00.txt

&n= bsp;

I haven=92t read the most current versi= on, but I think it=92s fair to say I=92ve provided most of the public non-p= olitical feedback to MODERN so far.=

 

The last comments I made advocated for = the use of .name. domain name space (or a new name space) tied to telephone= numbers with the concept of MODERN hosting Communications Reachability Information (CRI) and that index keys into a CRI database cou= ld be passwords which could also be telephone numbers.

 

The idea was cheerfully disregarded but= I will bring it up again.  The MODERN =93problem statement=94 is a so= lution architecture (not a problem statement), and it=92s inadequate, and centric to NANP telephony considerations.

 

If you want a globally usable telephone= number routing information model for IP-based telecommunications and you w= ant to more usefully solve problems like calling identity authentication (globally) and non-geographic number portability (= for NANP), you should seriously be looking at multi-factor authentication f= or routing information queries.  Factors such as who do you think you= =92re calling? And, what is the number [password] you think is associated with them?=

 

You send a query to the CRI and you onl= y know one factor (e.g., telephone number)?  That provides you an inde= x into the least useful telecommunications information.  Perhaps only a telephone number into a SPAM-only voicemail box or voice-to= -text-to-SPAM-text-box or whatever the user has defined that protects them = from unauthorized and unauthenticated communications attempts.  Create= a multi-factor communications model (which SIP and other communications protocols easily and commonly support)= and you can have a meaninful impact on global robo-calling and robo-textin= g SPAM.

 

I have 3 main telephone numbers that ar= e unique to me.  Very few people have all 3.  I compartmentalize = my communications based on whether they are private, family, or business.  I could easily want or have more.  Many people do.=   Very few people purposefully distribute all of their telephone numbe= rs, e-mail addresses, social network personas, et cetera to all of their pr= ivate, family, and work contacts.

 

If you want to give users globally, the= world over, control over CRI, build a model that addresses their communica= tions reachability needs, not their voice telephony needs.

 

Regards,

 

Pierce

 

From= : Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: July 07, 2016 12:33 PM
To: Steve Donovan <sr= donovan@usdonovans.com>; modern@ietf.org
Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-= 00.txt

 =

 <= /span>

Thanks = Steve, I cleaned these up.

 <= /span>

Jon Pet= erson

Neustar= , Inc.

 <= /span>

From= : Modern <modern-bounces@ietf.org> on beh= alf of Steve Donovan <srdono= van@usdonovans.com>
Date: Friday, June 24, 2016 at 12:21 PM
To: "modern@ietf.org&quo= t; <modern@ietf.org>
Subject: [Modern] Review of draft-ietf-modern-problem-framework-00.t= xt

 <= /span>

I have = reviewed draft-ietf-modern-problem-framework-00.txt.  This document is in = great shape and I only have editorial comments as follows.

Regards,

Steve

-----

Section 1:

s /familiar from the/familiar to the/
s/ manenr/manner/
s/evolvling/evolving/

Section 2.1
s/assginees/assignees/
s/entitiy/entity/

Section 3
Need references for DRINKS and WEIRDS

Section 4.1.4
s/Aquiring/Acquiring/

Section 4.1.5
s/wtih/with/

Section 4.2.1.2
s/Regisrar/Registrar/

Section 4.1.2.3
s/could could/could/

Section 4.3.2
s/to access to this/to access this/


&n= bsp;


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_D3A41A431A5135jonpetersonneustarbiz_-- From nobody Thu Jul 7 15:02:27 2016 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA0F12D59A for ; Thu, 7 Jul 2016 15:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 DaVmCd798Rff for ; Thu, 7 Jul 2016 15:02:20 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0106.outbound.protection.outlook.com [104.47.42.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5453712D532 for ; Thu, 7 Jul 2016 15:02:20 -0700 (PDT) Received: from BY2FFO11FD037.protection.gbl (10.1.14.34) by BY2FFO11HUB034.protection.gbl (10.1.14.118) with Microsoft SMTP Server (TLS) id 15.1.523.9; Thu, 7 Jul 2016 22:02:18 +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 BY2FFO11FD037.mail.protection.outlook.com (10.1.14.222) with Microsoft SMTP Server (TLS) id 15.1.534.7 via Frontend Transport; Thu, 7 Jul 2016 22:02:18 +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 u67LdY8c036102; Thu, 7 Jul 2016 17:02:17 -0500 Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by plsapdm2.corp.sprint.com with ESMTP id 241vtr14m9-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 07 Jul 2016 17:02:17 -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.1178.4; Thu, 7 Jul 2016 18:02:16 -0400 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.1178.000; Thu, 7 Jul 2016 17:02:16 -0500 From: "Gorman, Pierce A [CTO]" To: "Peterson, Jon" , Steve Donovan , "modern@ietf.org" Thread-Topic: [Modern] Review of draft-ietf-modern-problem-framework-00.txt Thread-Index: AQHRzk2U1S3ChqfLdUehwOlnB0jAB6ANooUA//+2tyCAAIKuAP//rLGwgABhuYD//66i4A== Date: Thu, 7 Jul 2016 22:02:15 +0000 Message-ID: <3f8a46d2e0e04d12af45e924c7784a56@PLSWE13M08.ad.sprint.com> References: <8caed92a03be4425ae31261887b475b7@PLSWE13M08.ad.sprint.com> <14fce615e6d340c49ae8ac4035f97e97@PLSWE13M08.ad.sprint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.44] Content-Type: multipart/alternative; boundary="_000_3f8a46d2e0e04d12af45e924c7784a56PLSWE13M08adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.172.38; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(7916002)(2980300002)(438002)(189002)(377454003)(199003)(19300405004)(5003600100003)(6806005)(4546004)(19580395003)(586003)(7846002)(106116001)(230783001)(102836003)(24736003)(107886002)(512954002)(790700001)(2501003)(7736002)(7696003)(3846002)(19580405001)(260700001)(30436002)(2950100001)(6116002)(68736007)(2906002)(8936002)(87936001)(81166006)(84326002)(11100500001)(106466001)(33646002)(356003)(108616004)(93886004)(81156014)(8676002)(54356999)(5250100002)(92566002)(86362001)(50986999)(15975445007)(5001770100001)(189998001)(16236675004)(97736004)(19625215002)(2900100001)(551544002)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB034; H:plsapdm2.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD037; 1:J65ybQatlVauPxeGEQcxiqzBZm5Rms2S+ojKZTNLFg6XyeNQckNRBvj0xPOlqV4B4I1RN5oxSMllz6QeZ923HJ0CSLsVl9QRjo5hgvRk02Ii3O0uk0eb906BqMWyVdfnaaYyxmMgdOLRUpSSgaYQWescVYhZB+Ol9kpz+eIC1bOoZEfNt4Wgmwous+LIFqyAnKnBpalUYPGHL5+3Afwpq6v1kzLDaz9BMkOi/2Ap1Hcg34JABqmsaWYLXs5e/GDFipBnSw7Xxyu06EgwmsgQmj+W2Fh4pPfJGpA4Ba/Cjs9wm8YrmGCXLcwIb+SWbfnvZPd/MViWtgwsdGqIxF3c1EwS66havwb8kTZ19iy1jBABBL5KvhI/pKKkNA2ZnUC2C69T44yFseJtCOd8xP211VrkyLzzRf8UERMMUg7WUUMFn9vtQV8v/TAEDaEZ2w1+yPY5X3YNHOFwgh3wMpkxyoLrAn/Fo1bfVZf5Hug2UFdYalQ1VKwlISBMT3D4DlrjbEASjD8QKH00tsPoORd43XGzk+Qrzu8hIVx16xMbUszFwvLLWJ/6e4DBSAB78HWo X-MS-Office365-Filtering-Correlation-Id: 929eecfc-77ac-488c-3b42-08d3a6b25d12 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB034; 2:K3e8VCDyyR4JimznLIkUSOGCLDeVqiRYoX3+TSQi7QaXgEXtPED3OWEsmpOMWrXWteFU9KVqTf14PGJCtfxXIA1qce0Vzabw8p34MCy+MyOSZePufJ9uWXLpV9VO5fpsCEvNh/ivJcRouuf/NtCdyJNdNgsL9nBbUOG42xMm7KB+L7FCUEkGkS6DBJdvT9M1; 3:c21jF0+l6ZKhodKzhy9W0Aaz+gbeIlgmfcUD/X35Mkb2yetY831Yr4+DhPj4GduGysxEbsTdvAfJyI0OVH7QXGxo4w26wmSR3lRZPwdn9qpLwUuTVjpMljr+fVaI3Npjx3ZX2hSfYWizAbeaAJpN/htiK/Y8GZi6un4LdhnKnZPODpPaW+6CldyFkKJZW4b8ouJplm8ba90O+r9TBW+BHh57x7X7YtWgWNxjVAvEYCST+J0QNmHXmL2W8Zmg/MkHIcBe/dN4vPHi4ReCtVrUmw== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BY2FFO11HUB034; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2FFO11HUB034; 25:l6SJ9HG4Lf4gdNAL0qgsjluH6TV4U6WIHyAX0/So?= =?us-ascii?Q?beUxOBK1nEdmU1uVOKW0cO7z7HPZ+79ovKlfSzBQHovnFpUtghD9G2qVqijC?= =?us-ascii?Q?TdhvfdhvvgSM2ChQzVmyofq8Y2R356TPfWhv2eoJj2Cjim37jQR6dzG7trLb?= =?us-ascii?Q?7pDRC088IRTsLBsZPEE+8egy6FyFyJAwwpouy9muXN8pFz/3AiUpSndJ5LRW?= =?us-ascii?Q?/+BefX5e4+4FJ3dQQg/FUb1yaKIigWI+dupO1ax2QglLjRpxTxNwzlc/kyS1?= =?us-ascii?Q?oJT7dzBFw5Ye0Lf1mn7suyCj/pfqLhlVuNXI1hqJ4+xHZVOWJgTkO9TdnfWK?= =?us-ascii?Q?5VkRgL42rhrRu1Ghf4Fx+nzPpA5DQTqalZHykbtWiqRHOfnM9fkKDhbaS4Tl?= =?us-ascii?Q?YzDd3baRy9Bv4Rei42HRuJLNBuNPWKNW/eQABG72v9tidmcLyBT1BeVcZ047?= =?us-ascii?Q?GbYJ1tb6mnTGrALDmv/bYtQlX2qbEeMvwJFW2oY4jRk/W7VMe3mLjE8+zk3A?= =?us-ascii?Q?9FKlQV05Uf5hAfbpeVb+fqpizBRhvN2SCF0cs9pi0E4E12wyDO2RPDAWaUsO?= =?us-ascii?Q?rsj6Z0h5DMvfh6Svujt7zI9LHvkRSexKCBbgdFkQHBYDzID71W/IKzEgbiCD?= =?us-ascii?Q?63/Xl9RIyPs/jVHDtrsI7icBU8yMe+EaJh+YoGW1zuSF0QkPqaZcSYOF8aL3?= =?us-ascii?Q?fXIopcA4g4iSECHBapBP5/1M1TcdbBQ8dbDTVjbfoCGHpgZqsIFPqMBBSZPH?= =?us-ascii?Q?euSZbFIKsBGYSna3Trlfe0orLoa3hLoc6hitFTMuQph5aBnY5MQ2Xrky6h0T?= =?us-ascii?Q?PbiCGDKhSIQqIuTyGrsOUouZmUEqdcBwpiGA7Mv1Osw4sesP8pPZmIcgdgKc?= =?us-ascii?Q?adLCMIqzkSv86hTbqLPI1gPgoecDg/erOBeM+1S9MVtigQJ4wrIG5jGLVf7M?= =?us-ascii?Q?TxkWffx1e2wGVyuHONeI5VEWIso1uj13qfE1uRO6SKh16ch2PDEb/8chAWGa?= =?us-ascii?Q?rAjuK2tGXDcnB80wZHGYriG41UokTZDmYFRVJCX+fbGry+DB63GOBrMmoro0?= =?us-ascii?Q?IcPyLWQ=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB034; 20:jiYG8cnIGGD9LOafqKbhMszfX4KEeVAB+CqOEpOeSpYE2DATeJMI4Gk9CrEAm1iKarSCMi7ZsZY/2qpVMbMJjSZYCvYPRgx0DQlTg432DZRkfaAd82zaKUZY1Jreg3noAUckDNmQjM/MJn9aSfNz+7payC7ut4swNt2r0exm8kDhX6vcgxWqg/QaSO6VEJK3rUXua3FWNC4sewgZnGyA3qtExcpTxP892gT7uCMmmqn/2/Mc44TLKWUnfhzTSoCtwsoS0tqVZM/goLg6l9xRYobs9NSwriJLzdcvgL8JTnpJJcI5GgIH7cH/YE0tlbywbDf8PMNl3egaSbaVdpyc0T0OtLcg6UMwGtOf0LmBfavk3nrpQ3iEt7qDN8ZXK5xi8Q3Ivt8lQbEhTempObrzjDadlDdKXVfvCn/G/ti2WVk= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(192374486261705)(18430343700868)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(13018025)(5005006)(13024025)(13023025)(13015025)(13017025)(3002001)(10201501046)(6055026); SRVR:BY2FFO11HUB034; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB034; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB034; 4:BcnyreMu2tCDDuMLn7ql4QLNU7VjboK80ee6zoLmfOJva7JM9frWDH7gSbBQaFvuFxEuflm9fV/wxHmamBmc4fmQWmfMqOKerc29AMeC8MYh7KJKGJQe7iejxlQ5nq3Jtmin8Lp+RZv7vmnfQP4FcrVVW0Rq8mNoKSGC/WhzVOdJ0HrJ/SY9mLUGlBlMR+IvjPX2UaFBbZJwnC3BKF+WZrm3vklzq69g2ZvICGWYXyeGF0IL+gvmXPEhKHaCOSfja7s2jqBemSJSzWA6nC3qbyC/iXU8MB/r9IlC71jPCSfZztY7m3jSfMIIet4j5lrDtSR/lwRVphuw96iGsuTSOX8PVzEApy8jsRZrxnH0ml6qEFR3TOMfDzLPZLgy02GfYzpD/XOezsROoJOgVFwrBB5dbV2qg0lKzC7Q2QeaLsbVecGx8DGg+ADKcGc+3P0RCuKcjyEHfGa0/KrFBqxhZlCWWO9QxIVymHKe9Rfo5+wQIvexusxmTTvEIHMJBjJi/fu5djgczG7okeWVVlmtn+2c+bBzatz1H3GizBKzIzp9ttIPy9cI37bmcVCLdGKNYdKNAPdKDgrEUPa/xEaLHcRReERbVjKo9hjxhGEPQOOrZUko2JQ2j+Hnl8K4rWG1 X-Forefront-PRVS: 0996D1900D X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2FFO11HUB034; 23:juWrWfFMjjaSGktqx6h0oTO67CPZ3QbM3z3h88/9?= =?us-ascii?Q?xgMgDK+612PU9z6F5V8jCdWc/VHVgKLEJ+iyF/A2p5H29rnvGh9Tld7Csbkt?= =?us-ascii?Q?y2EbJjocvM+KXlGpxwTA+rrXxv5+ItcVfnsSCMrYGoANNDG9Oa5hucNpbOCg?= =?us-ascii?Q?5PYx2gzc6D2FfsO+JSDUvHbwdSQdf7Zok2eEnkcJQNN+8K0zsybDIeMTXTZP?= =?us-ascii?Q?SUKkYowQXd0NdwrGZaq1bCwuHJkJiKZdnPeXhVqfH/KbK7DvDg48T66sRKYH?= =?us-ascii?Q?PC7d6wYbtjDkF2t4fRMDq8dhiygmeM7qbyXsbwQJzemu22lauMjBDIwZPE0z?= =?us-ascii?Q?ITJig0GJYfim/59gYnUq8NRjYhHthSBNvw3OX0PZQ4gsvHiqiThrHoGG3YwW?= =?us-ascii?Q?wiCKEo5UBXIjeS3ZYPFBm7zP1LHbS4kwQBQ1gZP3gTS/cxdw1TC5r2etHChl?= =?us-ascii?Q?jnLRN5RrBhF8d4kZIJSPU9/OF6F/XdcRjp+XDSNgZgxhLwbJY0DE4YB1kzUt?= =?us-ascii?Q?oNa7Q8BldR5cdcswckZROjNUD+Iz3rePBauCyPhIv2qR6xsv/uxQ2Lqx7Xp/?= =?us-ascii?Q?mmjfiMMZlAHhd4BeFWrB5pv9OEOpdSdiWcWQ9+wEzIlFHSerEpjUgcZPwcGu?= =?us-ascii?Q?r6sZaEuWxXHaSiUHg3DbuLUWNlpEFQPXb/9p6Xkx1U2y1fDLWBYpJD+tsYhA?= =?us-ascii?Q?d4rvCJZBkGO/vP1Jeg2JjNOWa5A/Ftg4J0MHxwOhNYPZCnwiNrRPRkBML0Df?= =?us-ascii?Q?dMJXmg4Pa1KJBkXDLNQku5bFJ8XuLqJA82Bg60NoQNUb21sG2sFlty8pyn/t?= =?us-ascii?Q?UuWH/pR6iXsLi9BMKcOAGlnRsqZ1WieCk/iDOoTWljgFtr7KwMOI+2tc2crU?= =?us-ascii?Q?jihsZdOsJo71sp91SbAvXcD0PItlYtbpLeWj6B2bUzLhrTaqq+V1O3Tty1Ik?= =?us-ascii?Q?B4fs46vcmP9LVta6PhMKTNcnPpg5lar99AKjgvtU3/h8FLtZNy4DPseQN0g4?= =?us-ascii?Q?QvP/dQ6H87aSTHaOYIOjGP7Ao/8dgmIKWPPJmYZWuNrnMv10Pz7a51u+Q+rw?= =?us-ascii?Q?PFs/5EnSID0OtC4DqtVfzRWmx/uTrEkEodJ20eOkykg2AKplL/m6FvDIGqCN?= =?us-ascii?Q?grL0z9qlcmHKCJNBlbRURktrsQQxNt0XiLcCTm1oweGf5Cw5+7jiNzUr1qZX?= =?us-ascii?Q?sjtNttWmsIzKzvBpopmB3P1bmuzW4f0fNZmJRVY5vU7QILGBY/Y4AYxLI4ju?= =?us-ascii?Q?hoLihkq+Lw+Dj96wgMIJTeFhqfa0b47zPp0Icb10XwDo6ggHcyRqT/d4b7Hw?= =?us-ascii?Q?loQu3+QYG9AwEti46bwNrLhIAOJo4qgnICZiV1Ki/p2usompOXcu81bI5hbp?= =?us-ascii?Q?5jdOiOro8jrxdfvz4cKZasMtc82bSzIRNA8341K+m+hUEzG+5ltQ5kVAdMwJ?= =?us-ascii?Q?o25NethcCA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB034; 6:3wZ3nY9W/IUiYxxngi+WNFI/0GzHZps/tKXk49vnyHHNPKiBXWz2K2kT4QAhaNXRVITNMKCnkt3L65UdNyTFRkT6CsJodxdN6HwAEZiLx9qZUN+GZynWLYMOtyNOcCG36DamkC3WzdfAOCXB/OyCZTgahm/zZinRg820+ziQku7HXp5nMIIrYdfVaAg3FrQmLByPn8npd21mj/Z+qzwOjepJUsc5CCSrKi25rrg2hMC9XbGhFTAVnHPzXL6oAyfO4iQatgnNDO7z2rD2b/4vGQDrs3C64DUj336SpWohwAJmrJk6xflUkr51E7UamsGmj9j79ifXahE/yca9544V+PY3MHJIYlB/Hp9RrTprg/I=; 5:JK5Gh0heyl2XYctEir6lT/Qhf5qMDHY+bGOMVhjCV4Tkw2xkLhqL5JK76aU/GRn9RI/YuV8yaND3i5h8rvnoOlqDxfM7xwK0Sf3vjQFifkd20ypwtWli2idZxUTCvZJUf+5Vcsd7nl5FDezxz+p3lw==; 24:XNxosAsr3cpmfh9z7HreBchV2i3OCc7+d+qRryBLKMSwtIlKCr9GbnFGsTRfgsaInnmgrA9fve4vKYy+USPnf6kLmHqyNvLnVfLf4CG2Jy4=; 7:hn9Sj5+X0W2A/xbkuchdxDy64OQ/oMRjYfRjrpIq0hi643BV3CJsacMWB5niTacVpd3gqcm2gZWHSrNXrlMsc/kV4PCMvNKWhQEnym3yhhR7Cdy4tQySar1iXMpznB/luvbWOd/it55K3CS3Y0SgXSINkS320l9s9CGr+Ebu5TgueEL9jgJ89jbjU3K6xZ7KvUuPij2Yg+nGR0aETA+a8Xdt8S0Q4AgFCd1YsmwkKaoPAzPrOP1QOb/qm2Ji+oqi SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jul 2016 22:02:18.3209 (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: BY2FFO11HUB034 Archived-At: Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-00.txt X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Managing, 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, 07 Jul 2016 22:02:25 -0000 --_000_3f8a46d2e0e04d12af45e924c7784a56PLSWE13M08adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What makes you think the "IP transition of telephony" needs MODERN? Where = in any of the 3GPP tech specs for IMS does it refer to MODERN? Where do yo= u think the industry is headed with, or without MODERN? Robo-calling is a problem. IP transition of telephony is not. From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: July 07, 2016 4:50 PM To: Gorman, Pierce A [CTO] ; Steve Donovan ; modern@ietf.org Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-00.txt The question of whether you require multi-factor authentication to access r= eachability information or not is, actually, a very narrow implementation d= etail. There will of course be security requirements on accessing and chang= ing the data that our information model captures, and it could be that thos= e requirements will entail that multi-factor authorization is required - th= ough that the term "multi-factor authentication" also has a specific connot= ation in security design that might be a little different than what you mea= n here. But again - the bulk of our chartered work in MODERN is just figuri= ng out what that information model is. You're worrying about things that we= won't even get to until we've gone through much of that process. And while your problem statement below does state a specific problem, that = problem as stated doesn't happen to be the problem this group is chartered = to solve. Again, this group is much more concerned with the broader questio= n of how and why you might populate data associated with telephone numbers = for a variety of applications than with meeting any tactical industry goal = like reducing unwanted communications. Reducing unwanted communications cou= ld certainly be a very desirable side effect of some of the information mod= els we'd consider here, but that problem didn't motivate this working group= . I'm sure we don't need another history lesson, but this working group has= more to do with an IP transition of telephony in general than with any spe= cific ill we imagine that IP transition might exacerbate. Jon Peterson Neustar, Inc. From: "Gorman, Pierce A [CTO]" > Date: Thursday, July 7, 2016 at 2:38 PM To: Jon Peterson = >, Steve Donovan = >, "modern@ietf.org" > Subject: RE: [Modern] Review of draft-ietf-modern-problem-framework-00.txt You may be right. I may be (just as) guilty of solution jumping. I don't agree though that suggesting the use of standard security architect= ural approaches (i.e., multi-factor authentication) to inter-system (or int= er-personal) communications requirements with respect to managing CRI is a = focus "on a narrow way of implementing this". A problem statement should state a problem. For example: Until user-level Communications Reachability Information (CRI) is modeled t= o include multiple factors of authenticity instead of a single factor (i.e.= , the "telephone number"), robo-calling and robo-texting will continue to b= e problems plaguing the global telecommunications infrastucture and it's us= ers. If we want the telephone network to be better at screening calls for users,= we need to provide more information to the network (and/or the user) to im= prove filtering. Authenticating calling numbers will be of very limited us= efulness as an anti-robo-calling filter. Including a password in a SIP URI = is trivial. Associating and storing credentials with a telephone number is= less so, but would be extremely useful as SPAM filters. MODERN shouldn't manage telephone numbers. MODERN should manage CRI. CRI = could include telephone numbers, e-mail and social application addresses, c= redentials for managing access to CRI data, and credentials used in signali= ng which assist in authenticating and filtering communications attempts. Pierce From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: July 07, 2016 3:59 PM To: Gorman, Pierce A [CTO] >; Steve Donovan >; modern@ietf.org Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-00.txt I think the only reason your idea here is being "cheerfully discarded," as = you put it, is that we're just not on the same page about what is an archit= ecture, versus a framework, versus a solution. What you're describing goes = beyond a problem statement, beyond even proposing an architecture or protoc= ol solution - it sketches an actual implementation that someone could offer= as a commercial product. We don't make those at the IETF. The irony in this misalignment of our understanding of working group's job = is that the MODERN charter is probably compatible with what you're proposin= g, as far as I can tell. A .name namespace allocated for this purpose of ex= posing reachability information would be an implementation of the "retrieva= l interface" component of the MODERN framework described in the problem sta= tement. The question of what "factors" you include in a query to the retrie= val interface is indeed one of the big ones we're interested in exploring -= we hope to eventually produce an information model that will capture what = those factors would be. We want to create an information model versatile en= ough to work with a number of distinct bindings (that is, protocols that mi= ght carry the query). But retrieval is only one component of the framework = we're developing, as we're also concerned with how identifiers get allocate= d (maybe how those .name domains get assigned?) and what information gets p= rovisioned against them (maybe what provisioning occurs so that your "facto= rs" help you get the reachability information you need?). So again, it's not that I'm even necessarily opposed to what you're proposi= ng, you're just not looking at the same parts of the problem that I am, and= you're apparently focused on a narrow way of implementing this. Implementi= ng will be the easy part. Getting the information model right is hard, and = that's the work we're chartered to do. Jon Peterson Neustar, Inc. From: "Gorman, Pierce A [CTO]" > Date: Thursday, July 7, 2016 at 11:38 AM To: Jon Peterson = >, Steve Donovan = >, "modern@ietf.org" > Subject: RE: [Modern] Review of draft-ietf-modern-problem-framework-00.txt I haven't read the most current version, but I think it's fair to say I've = provided most of the public non-political feedback to MODERN so far. The last comments I made advocated for the use of .name. domain name space = (or a new name space) tied to telephone numbers with the concept of MODERN = hosting Communications Reachability Information (CRI) and that index keys i= nto a CRI database could be passwords which could also be telephone numbers= . The idea was cheerfully disregarded but I will bring it up again. The MODE= RN "problem statement" is a solution architecture (not a problem statement)= , and it's inadequate, and centric to NANP telephony considerations. If you want a globally usable telephone number routing information model fo= r IP-based telecommunications and you want to more usefully solve problems = like calling identity authentication (globally) and non-geographic number p= ortability (for NANP), you should seriously be looking at multi-factor auth= entication for routing information queries. Factors such as who do you thi= nk you're calling? And, what is the number [password] you think is associat= ed with them? You send a query to the CRI and you only know one factor (e.g., telephone n= umber)? That provides you an index into the least useful telecommunication= s information. Perhaps only a telephone number into a SPAM-only voicemail = box or voice-to-text-to-SPAM-text-box or whatever the user has defined that= protects them from unauthorized and unauthenticated communications attempt= s. Create a multi-factor communications model (which SIP and other communi= cations protocols easily and commonly support) and you can have a meaninful= impact on global robo-calling and robo-texting SPAM. I have 3 main telephone numbers that are unique to me. Very few people hav= e all 3. I compartmentalize my communications based on whether they are pr= ivate, family, or business. I could easily want or have more. Many people= do. Very few people purposefully distribute all of their telephone number= s, e-mail addresses, social network personas, et cetera to all of their pri= vate, family, and work contacts. If you want to give users globally, the world over, control over CRI, build= a model that addresses their communications reachability needs, not their = voice telephony needs. Regards, Pierce From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: July 07, 2016 12:33 PM To: Steve Donovan >; modern@ietf.org Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-00.txt Thanks Steve, I cleaned these up. Jon Peterson Neustar, Inc. From: Modern > on b= ehalf of Steve Donovan > Date: Friday, June 24, 2016 at 12:21 PM To: "modern@ietf.org" > Subject: [Modern] Review of draft-ietf-modern-problem-framework-00.txt I have reviewed draft-ietf-modern-problem-framework-00.txt. This document = is in great shape and I only have editorial comments as follows. Regards, Steve ----- Section 1: s /familiar from the/familiar to the/ s/ manenr/manner/ s/evolvling/evolving/ Section 2.1 s/assginees/assignees/ s/entitiy/entity/ Section 3 Need references for DRINKS and WEIRDS Section 4.1.4 s/Aquiring/Acquiring/ Section 4.1.5 s/wtih/with/ Section 4.2.1.2 s/Regisrar/Registrar/ Section 4.1.2.3 s/could could/could/ Section 4.3.2 s/to access to this/to access this/ ________________________________ 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_3f8a46d2e0e04d12af45e924c7784a56PLSWE13M08adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What makes you think the “IP tran= sition of telephony” needs MODERN?  Where in any of the 3GPP tec= h specs for IMS does it refer to MODERN?  Where do you think the industry is headed with, or without MODERN?

 

Robo-calling is a problem.  IP tra= nsition of telephony is not.

 

 

From:= Peterson, Jon [mailto:jon.peterson@neusta= r.biz]
Sent: July 07, 2016 4:50 PM
To: Gorman, Pierce A [CTO] <Pierce.Gorman@sprint.com>; Steve D= onovan <srdonovan@usdonovans.com>; modern@ietf.org
Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-= 00.txt

 

&n= bsp;

The que= stion of whether you require multi-factor authentication to access reachabi= lity information or not is, actually, a very narrow implementation detail. = There will of course be security requirements on accessing and changing the data that our information model captures, an= d it could be that those requirements will entail that multi-factor authori= zation is required - though that the term "multi-factor authentication= " also has a specific connotation in security design that might be a little different than what you mean here. = But again - the bulk of our chartered work in MODERN is just figuring out w= hat that information model is. You're worrying about things that we won't e= ven get to until we've gone through much of that process.

&n= bsp;

And whi= le your problem statement below does state a specific problem, that problem= as stated doesn't happen to be the problem this group is chartered to solv= e. Again, this group is much more concerned with the broader question of how and why you might populate data associate= d with telephone numbers for a variety of applications than with meeting an= y tactical industry goal like reducing unwanted communications. Reducing un= wanted communications could certainly be a very desirable side effect of some of the information models we'd con= sider here, but that problem didn't motivate this working group. I'm sure w= e don't need another history lesson, but this working group has more to do = with an IP transition of telephony in general than with any specific ill we imagine that IP transition might = exacerbate. 

&n= bsp;

Jon Pet= erson

Neustar= , Inc.

&n= bsp;

From= : "Gorman, Pie= rce A [CTO]" <Pierce.Go= rman@sprint.com>
Date: Thursday, July 7, 2016 at 2:38 PM
To: Jon Peterson <jon= .peterson@neustar.biz>, Steve Donovan <srdonovan@usdonovans.com>, "modern@ietf.org" <modern@ietf.org>
Subject: RE: [Modern] Review of draft-ietf-modern-problem-framework-= 00.txt

&n= bsp;

You may be right.  I may be (just = as) guilty of solution jumping.

 

I don’t agree though that suggest= ing the use of standard security architectural approaches (i.e., multi-fact= or authentication) to inter-system (or inter-personal) communications requirements with respect to managing CRI is a focus “= ;on a narrow way of implementing this”.

 

A problem statement should state a prob= lem.

 

For example:

 

Until user-l= evel Communications Reachability Information (CRI) is modeled to include mu= ltiple factors of authenticity instead of a single factor (i.e., the “telephone number”), robo-calling and robo-t= exting will continue to be problems plaguing the global telecommunications = infrastucture and it’s users.=

 

If we want the telephone network to be = better at screening calls for users, we need to provide more information to= the network (and/or the user) to improve filtering.  Authenticating calling numbers will be of very limited usefulness as an an= ti-robo-calling filter. Including a password in a SIP URI is trivial. = Associating and storing credentials with a telephone number is less so, bu= t would be extremely useful as SPAM filters.

 

MODERN shouldn’t manage telephone= numbers.  MODERN should manage CRI.  CRI could include telephone= numbers, e-mail and social application addresses, credentials for managing access to CRI data, and credentials used in signaling which a= ssist in authenticating and filtering communications attempts.

 

Pierce

 

From= : Peterson, Jon [mailto:jon.peterson@neustar.biz]
Sent: July 07, 2016 3:59 PM
To: Gorman, Pierce A [CTO] <Pierce.Gorman@sprint.com>; Steve Donovan <srdonovan@usdonovans.com>; modern@ietf.org
Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-= 00.txt

 =

 <= /span>

I think= the only reason your idea here is being "cheerfully discarded," = as you put it, is that we're just not on the same page about what is an arc= hitecture, versus a framework, versus a solution. What you're describing goes beyond a problem statement, beyond even propos= ing an architecture or protocol solution - it sketches an actual implementa= tion that someone could offer as a commercial product. We don't make those = at the IETF.

 <= /span>

The iro= ny in this misalignment of our understanding of working group's job is that= the MODERN charter is probably compatible with what you're proposing, as f= ar as I can tell. A .name namespace allocated for this purpose of exposing reachability information would be a= n implementation of the "retrieval interface" component of the MO= DERN framework described in the problem statement. The question of what &qu= ot;factors" you include in a query to the retrieval interface is indeed one of the big ones we're interested in exploring - we= hope to eventually produce an information model that will capture what tho= se factors would be. We want to create an information model versatile enoug= h to work with a number of distinct bindings (that is, protocols that might carry the query). But retrieval is= only one component of the framework we're developing, as we're also concer= ned with how identifiers get allocated (maybe how those .name domains get a= ssigned?) and what information gets provisioned against them (maybe what provisioning occurs so that your &quo= t;factors" help you get the reachability information you need?).

 <= /span>

So agai= n, it's not that I'm even necessarily opposed to what you're proposing, you= 're just not looking at the same parts of the problem that I am, and you're= apparently focused on a narrow way of implementing this. Implementing will be the easy part. Getting the info= rmation model right is hard, and that's the work we're chartered to do.

 <= /span>

Jon Pet= erson

Neustar= , Inc.

 <= /span>

From= : "Gorman, Pie= rce A [CTO]" <Pierce.Go= rman@sprint.com>
Date: Thursday, July 7, 2016 at 11:38 AM
To: Jon Peterson <jon= .peterson@neustar.biz>, Steve Donovan <srdonovan@usdonovans.com>, "modern@ietf.org" <modern@ietf.org>
Subject: RE: [Modern] Review of draft-ietf-modern-problem-framework-= 00.txt

 <= /span>

I haven’t read the most current v= ersion, but I think it’s fair to say I’ve provided most of the = public non-political feedback to MODERN so far.

 

The last comments I made advocated for = the use of .name. domain name space (or a new name space) tied to telephone= numbers with the concept of MODERN hosting Communications Reachability Information (CRI) and that index keys into a CRI database cou= ld be passwords which could also be telephone numbers.

 

The idea was cheerfully disregarded but= I will bring it up again.  The MODERN “problem statement”= is a solution architecture (not a problem statement), and it’s inadequate, and centric to NANP telephony considerations.

 

If you want a globally usable telephone= number routing information model for IP-based telecommunications and you w= ant to more usefully solve problems like calling identity authentication (globally) and non-geographic number portability (= for NANP), you should seriously be looking at multi-factor authentication f= or routing information queries.  Factors such as who do you think you&= #8217;re calling? And, what is the number [password] you think is associated with them?=

 

You send a query to the CRI and you onl= y know one factor (e.g., telephone number)?  That provides you an inde= x into the least useful telecommunications information.  Perhaps only a telephone number into a SPAM-only voicemail box or voice-to= -text-to-SPAM-text-box or whatever the user has defined that protects them = from unauthorized and unauthenticated communications attempts.  Create= a multi-factor communications model (which SIP and other communications protocols easily and commonly support)= and you can have a meaninful impact on global robo-calling and robo-textin= g SPAM.

 

I have 3 main telephone numbers that ar= e unique to me.  Very few people have all 3.  I compartmentalize = my communications based on whether they are private, family, or business.  I could easily want or have more.  Many people do.=   Very few people purposefully distribute all of their telephone numbe= rs, e-mail addresses, social network personas, et cetera to all of their pr= ivate, family, and work contacts.

 

If you want to give users globally, the= world over, control over CRI, build a model that addresses their communica= tions reachability needs, not their voice telephony needs.

 

Regards,

 

Pierce

 

From= : Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: July 07, 2016 12:33 PM
To: Steve Donovan <sr= donovan@usdonovans.com>; modern@ietf.org
Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-= 00.txt

 =

 <= /span>

Thanks = Steve, I cleaned these up.

 <= /span>

Jon Pet= erson

Neustar= , Inc.

 <= /span>

From= : Modern <modern-bounces@ietf.org> on beh= alf of Steve Donovan <srdono= van@usdonovans.com>
Date: Friday, June 24, 2016 at 12:21 PM
To: "modern@ietf.org&quo= t; <modern@ietf.org>
Subject: [Modern] Review of draft-ietf-modern-problem-framework-00.t= xt

 <= /span>

I have = reviewed draft-ietf-modern-problem-framework-00.txt.  This document is in = great shape and I only have editorial comments as follows.

Regards,

Steve

-----

Section 1:

s /familiar from the/familiar to the/
s/ manenr/manner/
s/evolvling/evolving/

Section 2.1
s/assginees/assignees/
s/entitiy/entity/

Section 3
Need references for DRINKS and WEIRDS

Section 4.1.4
s/Aquiring/Acquiring/

Section 4.1.5
s/wtih/with/

Section 4.2.1.2
s/Regisrar/Registrar/

Section 4.1.2.3
s/could could/could/

Section 4.3.2
s/to access to this/to access this/



 <= /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_3f8a46d2e0e04d12af45e924c7784a56PLSWE13M08adsprintcom_-- From nobody Thu Jul 7 15:12:57 2016 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE1812D14D for ; Thu, 7 Jul 2016 15:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 IKvGRbSOyT-i for ; Thu, 7 Jul 2016 15:12:51 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FA6312D100 for ; Thu, 7 Jul 2016 15:12:51 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u67M2xwk011109; Thu, 7 Jul 2016 18:12:51 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 23x88v3p2n-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 07 Jul 2016 18:12:50 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 7 Jul 2016 18:12:49 -0400 From: "Peterson, Jon" To: "Gorman, Pierce A [CTO]" , Steve Donovan , "modern@ietf.org" Thread-Topic: [Modern] Review of draft-ietf-modern-problem-framework-00.txt Thread-Index: AQHRzk2W0VnsFaP+xEeTcvTqXwlhyKANHGCAgACHgQD//7HpgIAAgF6A//+ODACAAHivgP//jZYA Date: Thu, 7 Jul 2016 22:12:48 +0000 Message-ID: References: <8caed92a03be4425ae31261887b475b7@PLSWE13M08.ad.sprint.com> <14fce615e6d340c49ae8ac4035f97e97@PLSWE13M08.ad.sprint.com> <3f8a46d2e0e04d12af45e924c7784a56@PLSWE13M08.ad.sprint.com> In-Reply-To: <3f8a46d2e0e04d12af45e924c7784a56@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.6.3.160329 x-originating-ip: [10.96.12.185] Content-Type: multipart/alternative; boundary="_000_D3A421421A5167jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-07_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607070205 Archived-At: Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-00.txt X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Managing, 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, 07 Jul 2016 22:12:56 -0000 --_000_D3A421421A5167jonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think at this point we're stomping on ground we've traveled before, and t= he only answers I can give would be history lessons. I believe the view I e= xpressed captures what this group is chartered to do. Whether or not anyone actually uses the information models or other outputs= of the MODERN working group will depend entirely on how suitable they turn= out to b for the various stakeholders that need tools in a post-IP transit= ion world. Part of this exercise is predicting what those will be as well a= s we can. If we get it wrong, the worst thing that will happen is that peop= le like me will have wasted their time. Jon Peterson Neustar, Inc. From: "Gorman, Pierce A [CTO]" > Date: Thursday, July 7, 2016 at 3:02 PM To: Jon Peterson = >, Steve Donovan = >, "modern@ietf.org" > Subject: RE: [Modern] Review of draft-ietf-modern-problem-framework-00.txt What makes you think the =93IP transition of telephony=94 needs MODERN? Wh= ere in any of the 3GPP tech specs for IMS does it refer to MODERN? Where d= o you think the industry is headed with, or without MODERN? Robo-calling is a problem. IP transition of telephony is not. From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: July 07, 2016 4:50 PM To: Gorman, Pierce A [CTO] >; Steve Donovan >; modern@ietf.org Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-00.txt The question of whether you require multi-factor authentication to access r= eachability information or not is, actually, a very narrow implementation d= etail. There will of course be security requirements on accessing and chang= ing the data that our information model captures, and it could be that thos= e requirements will entail that multi-factor authorization is required - th= ough that the term "multi-factor authentication" also has a specific connot= ation in security design that might be a little different than what you mea= n here. But again - the bulk of our chartered work in MODERN is just figuri= ng out what that information model is. You're worrying about things that we= won't even get to until we've gone through much of that process. And while your problem statement below does state a specific problem, that = problem as stated doesn't happen to be the problem this group is chartered = to solve. Again, this group is much more concerned with the broader questio= n of how and why you might populate data associated with telephone numbers = for a variety of applications than with meeting any tactical industry goal = like reducing unwanted communications. Reducing unwanted communications cou= ld certainly be a very desirable side effect of some of the information mod= els we'd consider here, but that problem didn't motivate this working group= . I'm sure we don't need another history lesson, but this working group has= more to do with an IP transition of telephony in general than with any spe= cific ill we imagine that IP transition might exacerbate. Jon Peterson Neustar, Inc. From: "Gorman, Pierce A [CTO]" > Date: Thursday, July 7, 2016 at 2:38 PM To: Jon Peterson = >, Steve Donovan = >, "modern@ietf.org" > Subject: RE: [Modern] Review of draft-ietf-modern-problem-framework-00.txt You may be right. I may be (just as) guilty of solution jumping. I don=92t agree though that suggesting the use of standard security archite= ctural approaches (i.e., multi-factor authentication) to inter-system (or i= nter-personal) communications requirements with respect to managing CRI is = a focus =93on a narrow way of implementing this=94. A problem statement should state a problem. For example: Until user-level Communications Reachability Information (CRI) is modeled t= o include multiple factors of authenticity instead of a single factor (i.e.= , the =93telephone number=94), robo-calling and robo-texting will continue = to be problems plaguing the global telecommunications infrastucture and it= =92s users. If we want the telephone network to be better at screening calls for users,= we need to provide more information to the network (and/or the user) to im= prove filtering. Authenticating calling numbers will be of very limited us= efulness as an anti-robo-calling filter. Including a password in a SIP URI = is trivial. Associating and storing credentials with a telephone number is= less so, but would be extremely useful as SPAM filters. MODERN shouldn=92t manage telephone numbers. MODERN should manage CRI. CR= I could include telephone numbers, e-mail and social application addresses,= credentials for managing access to CRI data, and credentials used in signa= ling which assist in authenticating and filtering communications attempts. Pierce From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: July 07, 2016 3:59 PM To: Gorman, Pierce A [CTO] >; Steve Donovan >; modern@ietf.org Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-00.txt I think the only reason your idea here is being "cheerfully discarded," as = you put it, is that we're just not on the same page about what is an archit= ecture, versus a framework, versus a solution. What you're describing goes = beyond a problem statement, beyond even proposing an architecture or protoc= ol solution - it sketches an actual implementation that someone could offer= as a commercial product. We don't make those at the IETF. The irony in this misalignment of our understanding of working group's job = is that the MODERN charter is probably compatible with what you're proposin= g, as far as I can tell. A .name namespace allocated for this purpose of ex= posing reachability information would be an implementation of the "retrieva= l interface" component of the MODERN framework described in the problem sta= tement. The question of what "factors" you include in a query to the retrie= val interface is indeed one of the big ones we're interested in exploring -= we hope to eventually produce an information model that will capture what = those factors would be. We want to create an information model versatile en= ough to work with a number of distinct bindings (that is, protocols that mi= ght carry the query). But retrieval is only one component of the framework = we're developing, as we're also concerned with how identifiers get allocate= d (maybe how those .name domains get assigned?) and what information gets p= rovisioned against them (maybe what provisioning occurs so that your "facto= rs" help you get the reachability information you need?). So again, it's not that I'm even necessarily opposed to what you're proposi= ng, you're just not looking at the same parts of the problem that I am, and= you're apparently focused on a narrow way of implementing this. Implementi= ng will be the easy part. Getting the information model right is hard, and = that's the work we're chartered to do. Jon Peterson Neustar, Inc. From: "Gorman, Pierce A [CTO]" > Date: Thursday, July 7, 2016 at 11:38 AM To: Jon Peterson = >, Steve Donovan = >, "modern@ietf.org" > Subject: RE: [Modern] Review of draft-ietf-modern-problem-framework-00.txt I haven=92t read the most current version, but I think it=92s fair to say I= =92ve provided most of the public non-political feedback to MODERN so far. The last comments I made advocated for the use of .name. domain name space = (or a new name space) tied to telephone numbers with the concept of MODERN = hosting Communications Reachability Information (CRI) and that index keys i= nto a CRI database could be passwords which could also be telephone numbers= . The idea was cheerfully disregarded but I will bring it up again. The MODE= RN =93problem statement=94 is a solution architecture (not a problem statem= ent), and it=92s inadequate, and centric to NANP telephony considerations. If you want a globally usable telephone number routing information model fo= r IP-based telecommunications and you want to more usefully solve problems = like calling identity authentication (globally) and non-geographic number p= ortability (for NANP), you should seriously be looking at multi-factor auth= entication for routing information queries. Factors such as who do you thi= nk you=92re calling? And, what is the number [password] you think is associ= ated with them? You send a query to the CRI and you only know one factor (e.g., telephone n= umber)? That provides you an index into the least useful telecommunication= s information. Perhaps only a telephone number into a SPAM-only voicemail = box or voice-to-text-to-SPAM-text-box or whatever the user has defined that= protects them from unauthorized and unauthenticated communications attempt= s. Create a multi-factor communications model (which SIP and other communi= cations protocols easily and commonly support) and you can have a meaninful= impact on global robo-calling and robo-texting SPAM. I have 3 main telephone numbers that are unique to me. Very few people hav= e all 3. I compartmentalize my communications based on whether they are pr= ivate, family, or business. I could easily want or have more. Many people= do. Very few people purposefully distribute all of their telephone number= s, e-mail addresses, social network personas, et cetera to all of their pri= vate, family, and work contacts. If you want to give users globally, the world over, control over CRI, build= a model that addresses their communications reachability needs, not their = voice telephony needs. Regards, Pierce From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: July 07, 2016 12:33 PM To: Steve Donovan >; modern@ietf.org Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-00.txt Thanks Steve, I cleaned these up. Jon Peterson Neustar, Inc. From: Modern > on b= ehalf of Steve Donovan > Date: Friday, June 24, 2016 at 12:21 PM To: "modern@ietf.org" > Subject: [Modern] Review of draft-ietf-modern-problem-framework-00.txt I have reviewed draft-ietf-modern-problem-framework-00.txt. This document = is in great shape and I only have editorial comments as follows. Regards, Steve ----- Section 1: s /familiar from the/familiar to the/ s/ manenr/manner/ s/evolvling/evolving/ Section 2.1 s/assginees/assignees/ s/entitiy/entity/ Section 3 Need references for DRINKS and WEIRDS Section 4.1.4 s/Aquiring/Acquiring/ Section 4.1.5 s/wtih/with/ Section 4.2.1.2 s/Regisrar/Registrar/ Section 4.1.2.3 s/could could/could/ Section 4.3.2 s/to access to this/to access this/ ________________________________ 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_D3A421421A5167jonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

I think at this point we're stomping on ground we've traveled before, = and the only answers I can give would be history lessons. I believe the vie= w I expressed captures what this group is chartered to do.

Whether or not anyone actually uses the information models or other ou= tputs of the MODERN working group will depend entirely on how suitable they= turn out to b for the various stakeholders that need tools in a post-IP tr= ansition world. Part of this exercise is predicting what those will be as well as we can. If we get it wrong, th= e worst thing that will happen is that people like me will have wasted thei= r time.

Jon Peterson
Neustar, Inc.

From: "Gorman, Pierce A [CTO]&= quot; <Pierce.Gorman@sprint.= com>
Date: Thursday, July 7, 2016 at 3:0= 2 PM
To: Jon Peterson <jon.peterson@neustar.biz>, Steve Donov= an <srdonovan@usdonovans.com= >, "modern@ietf.org"= ; <modern@ietf.org>
Subject: RE: [Modern] Review of dra= ft-ietf-modern-problem-framework-00.txt

What makes you think the =93IP transiti= on of telephony=94 needs MODERN?  Where in any of the 3GPP tech specs = for IMS does it refer to MODERN?  Where do you think the industry is headed with, or without MODERN?

 

Robo-calling is a problem.  IP tra= nsition of telephony is not.

 

 

From:= Peterson, Jon [mailto:jon.peterson@neustar.biz]
Sent: July 07, 2016 4:50 PM
To: Gorman, Pierce A [CTO] <Pierce.Gorman@sprint.com>; Steve Donovan <srdonovan@usdonovans.com>; modern@ietf.org
Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-= 00.txt

 

&n= bsp;

The que= stion of whether you require multi-factor authentication to access reachabi= lity information or not is, actually, a very narrow implementation detail. = There will of course be security requirements on accessing and changing the data that our information model captures, an= d it could be that those requirements will entail that multi-factor authori= zation is required - though that the term "multi-factor authentication= " also has a specific connotation in security design that might be a little different than what you mean here. = But again - the bulk of our chartered work in MODERN is just figuring out w= hat that information model is. You're worrying about things that we won't e= ven get to until we've gone through much of that process.

&n= bsp;

And whi= le your problem statement below does state a specific problem, that problem= as stated doesn't happen to be the problem this group is chartered to solv= e. Again, this group is much more concerned with the broader question of how and why you might populate data associate= d with telephone numbers for a variety of applications than with meeting an= y tactical industry goal like reducing unwanted communications. Reducing un= wanted communications could certainly be a very desirable side effect of some of the information models we'd con= sider here, but that problem didn't motivate this working group. I'm sure w= e don't need another history lesson, but this working group has more to do = with an IP transition of telephony in general than with any specific ill we imagine that IP transition might = exacerbate. 

&n= bsp;

Jon Pet= erson

Neustar= , Inc.

&n= bsp;

From= : "Gorman, Pie= rce A [CTO]" <Pierce.Go= rman@sprint.com>
Date: Thursday, July 7, 2016 at 2:38 PM
To: Jon Peterson <jon= .peterson@neustar.biz>, Steve Donovan <srdonovan@usdonovans.com>, "modern@ietf.org" <modern@ietf.org>
Subject: RE: [Modern] Review of draft-ietf-modern-problem-framework-= 00.txt

&n= bsp;

You may be right.  I may be (just = as) guilty of solution jumping.

 

I don=92t agree though that suggesting = the use of standard security architectural approaches (i.e., multi-factor a= uthentication) to inter-system (or inter-personal) communications requirements with respect to managing CRI is a focus =93on = a narrow way of implementing this=94.

 

A problem statement should state a prob= lem.

 

For example:

 

Until user-l= evel Communications Reachability Information (CRI) is modeled to include mu= ltiple factors of authenticity instead of a single factor (i.e., the =93telephone number=94), robo-calling and robo-texting w= ill continue to be problems plaguing the global telecommunications infrastu= cture and it=92s users.

 

If we want the telephone network to be = better at screening calls for users, we need to provide more information to= the network (and/or the user) to improve filtering.  Authenticating calling numbers will be of very limited usefulness as an an= ti-robo-calling filter. Including a password in a SIP URI is trivial. = Associating and storing credentials with a telephone number is less so, bu= t would be extremely useful as SPAM filters.

 

MODERN shouldn=92t manage telephone num= bers.  MODERN should manage CRI.  CRI could include telephone num= bers, e-mail and social application addresses, credentials for managing access to CRI data, and credentials used in signaling which a= ssist in authenticating and filtering communications attempts.

 

Pierce

 

From= : Peterson, Jon [mailto:jon.peterson@neustar.biz]
Sent: July 07, 2016 3:59 PM
To: Gorman, Pierce A [CTO] <Pierce.Gorman@sprint.com>; Steve Donovan <srdonovan@usdonovans.com>; modern@ietf.org
Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-= 00.txt

 =

 <= /span>

I think= the only reason your idea here is being "cheerfully discarded," = as you put it, is that we're just not on the same page about what is an arc= hitecture, versus a framework, versus a solution. What you're describing goes beyond a problem statement, beyond even propos= ing an architecture or protocol solution - it sketches an actual implementa= tion that someone could offer as a commercial product. We don't make those = at the IETF.

 <= /span>

The iro= ny in this misalignment of our understanding of working group's job is that= the MODERN charter is probably compatible with what you're proposing, as f= ar as I can tell. A .name namespace allocated for this purpose of exposing reachability information would be a= n implementation of the "retrieval interface" component of the MO= DERN framework described in the problem statement. The question of what &qu= ot;factors" you include in a query to the retrieval interface is indeed one of the big ones we're interested in exploring - we= hope to eventually produce an information model that will capture what tho= se factors would be. We want to create an information model versatile enoug= h to work with a number of distinct bindings (that is, protocols that might carry the query). But retrieval is= only one component of the framework we're developing, as we're also concer= ned with how identifiers get allocated (maybe how those .name domains get a= ssigned?) and what information gets provisioned against them (maybe what provisioning occurs so that your &quo= t;factors" help you get the reachability information you need?).

 <= /span>

So agai= n, it's not that I'm even necessarily opposed to what you're proposing, you= 're just not looking at the same parts of the problem that I am, and you're= apparently focused on a narrow way of implementing this. Implementing will be the easy part. Getting the info= rmation model right is hard, and that's the work we're chartered to do.

 <= /span>

Jon Pet= erson

Neustar= , Inc.

 <= /span>

From= : "Gorman, Pie= rce A [CTO]" <Pierce.Go= rman@sprint.com>
Date: Thursday, July 7, 2016 at 11:38 AM
To: Jon Peterson <jon= .peterson@neustar.biz>, Steve Donovan <srdonovan@usdonovans.com>, "modern@ietf.org" <modern@ietf.org>
Subject: RE: [Modern] Review of draft-ietf-modern-problem-framework-= 00.txt

 <= /span>

I haven=92t read the most current versi= on, but I think it=92s fair to say I=92ve provided most of the public non-p= olitical feedback to MODERN so far.=

 

The last comments I made advocated for = the use of .name. domain name space (or a new name space) tied to telephone= numbers with the concept of MODERN hosting Communications Reachability Information (CRI) and that index keys into a CRI database cou= ld be passwords which could also be telephone numbers.

 

The idea was cheerfully disregarded but= I will bring it up again.  The MODERN =93problem statement=94 is a so= lution architecture (not a problem statement), and it=92s inadequate, and centric to NANP telephony considerations.

 

If you want a globally usable telephone= number routing information model for IP-based telecommunications and you w= ant to more usefully solve problems like calling identity authentication (globally) and non-geographic number portability (= for NANP), you should seriously be looking at multi-factor authentication f= or routing information queries.  Factors such as who do you think you= =92re calling? And, what is the number [password] you think is associated with them?=

 

You send a query to the CRI and you onl= y know one factor (e.g., telephone number)?  That provides you an inde= x into the least useful telecommunications information.  Perhaps only a telephone number into a SPAM-only voicemail box or voice-to= -text-to-SPAM-text-box or whatever the user has defined that protects them = from unauthorized and unauthenticated communications attempts.  Create= a multi-factor communications model (which SIP and other communications protocols easily and commonly support)= and you can have a meaninful impact on global robo-calling and robo-textin= g SPAM.

 

I have 3 main telephone numbers that ar= e unique to me.  Very few people have all 3.  I compartmentalize = my communications based on whether they are private, family, or business.  I could easily want or have more.  Many people do.=   Very few people purposefully distribute all of their telephone numbe= rs, e-mail addresses, social network personas, et cetera to all of their pr= ivate, family, and work contacts.

 

If you want to give users globally, the= world over, control over CRI, build a model that addresses their communica= tions reachability needs, not their voice telephony needs.

 

Regards,

 

Pierce

 

From= : Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: July 07, 2016 12:33 PM
To: Steve Donovan <sr= donovan@usdonovans.com>; modern@ietf.org
Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-= 00.txt

 =

 <= /span>

Thanks = Steve, I cleaned these up.

 <= /span>

Jon Pet= erson

Neustar= , Inc.

 <= /span>

From= : Modern <modern-bounces@ietf.org> on beh= alf of Steve Donovan <srdono= van@usdonovans.com>
Date: Friday, June 24, 2016 at 12:21 PM
To: "modern@ietf.org&quo= t; <modern@ietf.org>
Subject: [Modern] Review of draft-ietf-modern-problem-framework-00.t= xt

 <= /span>

I have = reviewed draft-ietf-modern-problem-framework-00.txt.  This document is in = great shape and I only have editorial comments as follows.

Regards,

Steve

-----

Section 1:

s /familiar from the/familiar to the/
s/ manenr/manner/
s/evolvling/evolving/

Section 2.1
s/assginees/assignees/
s/entitiy/entity/

Section 3
Need references for DRINKS and WEIRDS

Section 4.1.4
s/Aquiring/Acquiring/

Section 4.1.5
s/wtih/with/

Section 4.2.1.2
s/Regisrar/Registrar/

Section 4.1.2.3
s/could could/could/

Section 4.3.2
s/to access to this/to access this/



 <= /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_D3A421421A5167jonpetersonneustarbiz_-- From nobody Fri Jul 8 14:31:00 2016 Return-Path: X-Original-To: modern@ietf.org Delivered-To: modern@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C6212D899; Fri, 8 Jul 2016 14:30:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708213053.32205.24906.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 14:30:53 -0700 Archived-At: Cc: modern@ietf.org Subject: [Modern] I-D Action: draft-ietf-modern-problem-framework-01.txt X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Managing, 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, 08 Jul 2016 21:30:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers of the IETF. Title : Modern Problem Statement, Use Cases, and Framework Authors : Jon Peterson Tom McGarry Filename : draft-ietf-modern-problem-framework-01.txt Pages : 22 Date : 2016-07-08 Abstract: The functions of the public switched telephone network (PSTN) are rapidly migrating to the Internet. This is generating new requirements for many traditional elements of the PSTN, including telephone numbers (TNs). TNs no longer serve simply as telephone routing addresses, they are now identifiers which may be used by Internet-based services for a variety of purposes including session establishment, identity verification, and service enablement. This problem statement examines how the existing tools for allocating and managing telephone numbers do not align with the use cases of the Internet environment, and proposes a framework for Internet-based services relying on TNs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-modern-problem-framework/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-modern-problem-framework-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-modern-problem-framework-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 16:54:14 2016 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8382812D9A1 for ; Fri, 8 Jul 2016 16:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnMqjzlg6Nor for ; Fri, 8 Jul 2016 16:54:10 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 3C535128B44 for ; Fri, 8 Jul 2016 16:53:57 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id f89so29053680qtd.2 for ; Fri, 08 Jul 2016 16:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=wWE/Qo1u3Duof1citi8KjiDQahkv/fMNh89MZ6Zld8U=; b=NWc2JdHE1DjTqx6026e3et0d+fk1u20lmLj11DyRqW001Om4XZIWMHfrvlfdCO3Ki+ lvGyeqg7vnTn/yfTkS5v7Xqp6WmIJTBgIjON90Ql4+ewc6xFixqVW+vJW9SLds7AUarI m5Xs44IyNcq31rFoKeFnkIQWdi0R5wPMM22ipwI1M5wltwSnT6LhCMTspXb38xPwBduK U1G0y8RX3/Ic0JmK/4rdCwePC99hBEQvPJSeINuabouoZT83pXrx7iO+Z2F9ZWb28kNk Fi3cGMBoTFJ7IcJl56n6B4m+QPNgLPtRM2jwFRphGt2q78i15GWpaYn3WGIzj8NIKmsr LQAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to; bh=wWE/Qo1u3Duof1citi8KjiDQahkv/fMNh89MZ6Zld8U=; b=Jf5GekQN4vlSua2gacLNwg8vK53aWpu0xAFrQTTGNjb0TnrOBM4wwgt1PXJIn/rp5a yzPOFjxKUBI5A0qMxtEZh0ul4kfcZ8JR4bmCnNTpHMOIxdcw7kzjpxVGWhKYrMZ4lTHf by1/ytdclnJnAyGz66o+zcx43456m0kHV4V78qbzIXDzZfvuxAxzPZamprIlFG6GKXQP XMR4A7YGT4Dan0VGHgoh0lDVXw0b/CCqPgacfeIOLEolXtTNUGtKf4+6R+k1Y7r/rdFj yeDSdBu07vTUBwz696+v6Qi+9dbgd1kP6nwTau+PiRvsyuu64wUc/Z2Qp1M4Bv5l5iFg c16w== X-Gm-Message-State: ALyK8tLTrJnfAcFbLFeVAUMwGlflh6Wsq9DLe6v+SMEb88B3vwdbBmmUxamDHfHbVCE5FQ== X-Received: by 10.200.54.59 with SMTP id m56mr12917085qtb.87.1468022036270; Fri, 08 Jul 2016 16:53:56 -0700 (PDT) Received: from ?IPv6:2601:41:c101:9364:d94:991e:dd5b:2958? ([2601:41:c101:9364:d94:991e:dd5b:2958]) by smtp.gmail.com with ESMTPSA id r81sm1689544qka.33.2016.07.08.16.53.55 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 08 Jul 2016 16:53:55 -0700 (PDT) From: Chris Wendt Content-Type: multipart/alternative; boundary="Apple-Mail=_F3A532B2-209F-4771-9279-F187CDBF7B85" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Fri, 8 Jul 2016 19:53:55 -0400 References: <20160708213053.32205.24906.idtracker@ietfa.amsl.com> To: Modern List In-Reply-To: <20160708213053.32205.24906.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Modern] updated draft-wendt-modern-drip-01 X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Managing, 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, 08 Jul 2016 23:54:12 -0000 --Apple-Mail=_F3A532B2-209F-4771-9279-F187CDBF7B85 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, I have submitted a new version of the DRiP draft. This includes updates to the Heartbeat API, a JWT based Authorization = header for transaction security and a few more notes on security. Comments are welcome. Thanks. -Chris A new version of I-D, draft-wendt-modern-drip-01.txt has been successfully submitted by Chris Wendt and posted to the IETF repository. Name: draft-wendt-modern-drip Revision: 01 Title: Distributed Registry Protocol Document date: 2016-07-08 Group: Individual Submission Pages: 16 URL: = https://www.ietf.org/internet-drafts/draft-wendt-modern-drip-01.txt = Status: = https://datatracker.ietf.org/doc/draft-wendt-modern-drip/ = Htmlized: https://tools.ietf.org/html/draft-wendt-modern-drip-01 = Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-wendt-modern-drip-01 = Abstract: This document describes a protocol for allowing a distributed set of nodes to synchronize a set of information in real-time with minimal amount of delay. This is useful for registry types of information like identity and telephone numbers with associated routing and ownership information and could be extended to support other distributed real-time information updates as well.= --Apple-Mail=_F3A532B2-209F-4771-9279-F187CDBF7B85 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi All,

I have submitted a new = version of the DRiP draft.

This includes updates to the Heartbeat API, a JWT based = Authorization header for transaction security and a few more notes on = security.

Comments are welcome.

Thanks.

-Chris

A new version of I-D, = draft-wendt-modern-drip-01.txt
has been successfully = submitted by Chris Wendt and posted to the
IETF = repository.

Name: = draft-wendt-modern-drip
Revision: 01
Title: Distributed Registry Protocol
Document = date: = 2016-07-08
Group: Individual Submission
Pages: 16
URL: =            https://www.ietf.org/internet-drafts/draft-wendt-modern-drip-01= .txt
Status: =         https://datatracker.ietf.org/doc/draft-wendt-modern-drip/Htmlized:       https://tools.ietf.org/html/draft-wendt-modern-drip-01
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-wendt-modern-drip-01<= /a>

Abstract:
  This = document describes a protocol for allowing a distributed set of
  nodes to synchronize a set of information in = real-time with minimal
  amount of delay. =  This is useful for registry types of information
  like identity and telephone numbers with = associated routing and
  ownership information = and could be extended to support other
  distributed real-time information updates as = well.
= --Apple-Mail=_F3A532B2-209F-4771-9279-F187CDBF7B85-- From nobody Sat Jul 9 06:48:19 2016 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDDE412D1B1 for ; Sat, 9 Jul 2016 06:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 OY1sO9uZz8hh for ; Sat, 9 Jul 2016 06:48:17 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B882512B03C for ; Sat, 9 Jul 2016 06:48:17 -0700 (PDT) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u69DhJAo011550 for ; Sat, 9 Jul 2016 09:48:17 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 242wcq0ayq-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT) for ; Sat, 09 Jul 2016 09:48:17 -0400 Received: from STNTEXMB11.cis.neustar.com ([169.254.1.169]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Sat, 9 Jul 2016 09:48:15 -0400 From: "McGarry, Tom" To: Modern List Thread-Topic: IETF 96 Draft Agenda Thread-Index: AQHR2eiKJnh26CRkMkGLJ0269vpKFA== Date: Sat, 9 Jul 2016 13:48:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [10.96.8.52] Content-Type: multipart/alternative; boundary="_000_D3A678DD38973tommcgarryneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-09_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=2 spamscore=2 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607090145 Archived-At: Subject: [Modern] IETF 96 Draft Agenda X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Managing, 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, 09 Jul 2016 13:48:19 -0000 --_000_D3A678DD38973tommcgarryneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments welcome. 5m Administrative, e.g., scribe, etc. - Chairs 5m draft-ietf-modern-problem-framework-01 - Jon Peterson 35m draft-peterson-modern-teri-01 - Jon Peterson 35m draft-wendt-modern-drip-01 - Chris Wendt 10m Discussion --_000_D3A678DD38973tommcgarryneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: <2F06446A206B5B4089A312C56A6CDF02@neustar.biz> Content-Transfer-Encoding: quoted-printable
Comments welcome.

5m   Administrative, e.g., scribe, etc. - Chairs
5m   draft-ietf-modern-problem-framework-01 - Jon Peterson
35m draft-peterson-modern-teri-01 - Jon Peterson
35m draft-wendt-modern-drip-01 - Chris Wendt
10m Discussion
--_000_D3A678DD38973tommcgarryneustarbiz_-- From nobody Wed Jul 20 02:35:54 2016 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2D612D0A5 for ; Wed, 20 Jul 2016 02:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 MXkejSc6fmQE for ; Wed, 20 Jul 2016 02:35:22 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54B0112B044 for ; Wed, 20 Jul 2016 02:35:14 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u6K92nvI001257 for ; Wed, 20 Jul 2016 05:11:43 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 24a2dp0b98-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 20 Jul 2016 05:11:42 -0400 Received: from STNTEXMB11.cis.neustar.com ([169.254.1.169]) by stntexhc10.cis.neustar.com ([169.254.4.225]) with mapi id 14.03.0279.002; Wed, 20 Jul 2016 05:11:42 -0400 From: "McGarry, Tom" To: Modern List Thread-Topic: IETF 96 Berlin Thread-Index: AQHR4ma6aPmwBON9xkW028YsBNzaJA== Date: Wed, 20 Jul 2016 09:11:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [10.96.9.121] Content-Type: multipart/alternative; boundary="_000_D3B4B88038F94tommcgarryneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-20_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=2 spamscore=2 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607200105 Archived-At: Subject: [Modern] IETF 96 Berlin X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 09:35:32 -0000 --_000_D3B4B88038F94tommcgarryneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Meeting today 2PM/14:00 Berlin time (8AM US Eastern time). Attendees, jabber scribe and note takers welcome. Presentations are on the site. Agenda: 5m Administrative, e.g., scribe, etc. - Chairs 5m draft-ietf-modern-problem-framework-01 - Jon Peterson 35m draft-peterson-modern-teri-01 - Jon Peterson 35m draft-wendt-modern-drip-01 - Chris Wendt 10m Discussion --_000_D3B4B88038F94tommcgarryneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: <14666C97DB1CBE41824D6590880F7674@neustar.biz> Content-Transfer-Encoding: quoted-printable
Meeting today 2PM/14:00 Berlin time (8AM US Eastern time).  

Attendees, jabber scribe and note takers welcome.  

Presentations are on the site.  

Agenda:
5m   Administrative, e.g., scribe, etc. - Chairs
5m   draft-ietf-modern-problem-framework-01 - Jon Peterson
35m draft-peterson-modern-teri-01 - Jon Peterson
35m draft-wendt-modern-drip-01 - Chris Wendt
10m Discussion
--_000_D3B4B88038F94tommcgarryneustarbiz_--