From nobody Thu Feb 1 12:54:41 2018 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 A497B12EC2C; Thu, 1 Feb 2018 12:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 uiBJltSkzMHB; Thu, 1 Feb 2018 12:54:38 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE22F12DA2B; Thu, 1 Feb 2018 12:54:35 -0800 (PST) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w11KsYcQ068596 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 1 Feb 2018 14:54:35 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: modern-chairs@ietf.org, "modern@ietf.org" , draft-ietf-modern-problem-framework@tools.ietf.org From: Adam Roach Message-ID: <50bbf1ae-5370-5d70-19b7-f47bcf2b94e6@nostrum.com> Date: Thu, 1 Feb 2018 14:54:29 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Modern] AD Evaluation: draft-ietf-modern-problem-framework-03 X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.22 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, 01 Feb 2018 20:54:41 -0000 I'm doing my AD evaluation of draft-ietf-modern-problem-framework-03. Thanks to everyone who has helped out with this work. Content-wise, this document looks very good to me. I have some editorial comments, but none of them are so severe to prevent sending it to IETF last call, which I will request shortly. Below, please find my editorial comments. Please treat these as IETF last call comments, and handle them at the same time as you deal with any comments that arise during that process. Thanks! > > Modern Problem Statement, Use Cases, and Framework > draft-ietf-modern-problem-framework-03.txt The title needs to make sense in a vacuum. I suggest "Problem Statement, Use Cases and Framework for Managing, Ordering, Distributing, Exposing, & Registering Telephone Numbers (MODERN)". > 2. Definitions > > ... > > Credential Authority: An entity that distributes credentials, such > as certificates that attest the authority of assignees (defined "...attest to the authority..." > below) and delegates. This document assumes that one of more "...one or more..." > +---------+ > |Numbering| > |Authority|Registry > +----+----+ > | > V 10,000 TNs > +---------+ > | CSP |Registrar > +----+----+ > | > V 100 TNs > +---------+ > | PBX |Assignee > +---------+ > | > V 1 TN > +---------+ > | User |Delegate > +---------+ > > Figure 1: Chain of Number Assignment These boxes, from top to bottom, are labeled with: Actor, Actor, Type of Hardware, Actor. I suggest that these should be consistent (e.g., change the third box from "PBX" to "Enterprise"). > 2.2. Data Types > > ... > > Semi-restricted: Only a subset of actors can access semi-restricted > data. For example CSPs may be able to access other CSP's service > data in some closed environment. "...closed environments." > 4. Use Cases > > The high-level use cases in this section will provide an overview of > the expected operation of the three interfaces in the MODERN problem > space: This is the first time we see "MODERN" in the document text. Please either qualify it (e.g., "...MODERN Working Group problem space:") or expand the acronym. > 4.1.1. Acquiring TNs from Registrar > > ... > Registrar, similarly to how such functions are conducted today when > Users purchase domain names. For the purpose of status information > kept by the Registry, TNs assigned to a User are always considered > assigned, not inventory.In this use case, after receiving a number Space between period and "In this use case..." > > 4.1.2. Acquiring TNs from CSPs > ... > Virtually the same flow would work for a reseller: it would form a > business relationship with the CSP, at which point the CSP would > collect and store administrative data about the reseller and give the > reseller any material needed for the reseller to acquire credentials > for the numbers. A user might then in turn acquire numbers from the > reseller: in this case, the delegate re-delegating the TNs would be > performing functions done by the CSP, e.g., providing any > credentials, collecting administrative data, or creative service > data. "...creating service data." > 4.2.2.1. CSP to other CSPs > > ... > If the CSP is assigning a TN from its own inventory it may not need > to perform service data updates as change occurs because the existing Replace "as change occurs" with either "as such a change occurs" or "as changes occur." > 4.2.3.1. Changing the CSP for an Existing Service > > Consider the case where a User who subscribes to a communications > service, and received their TN from that CSP, wishes to retain the > same TN but move their service to a different CSP. > > In the simplest scenario, where there's an authoritative combined "...where there is an..." > 4.3. Retrieval > > Retrieval of administrative or service data will be subject to access > restrictions based on the category of the specific data: public, > semi-restricted or restricted. Both administrative and service data > can have data elements that fall into each of these categories. It > is expected that the majority of administrative will fall into the "...of administrative data will..." > semi-restricted category: access to this information may require some > form of authorization, though service data crucial to reachability > will need to be accessible. In some environments, it's possible that "...it is possible..." > none of the service data necessary to initiate communications will be > useful to an entity on the public Internet, say, or that all that > service data will have dependencies on . The ending of this sentence is unsatisfying. I think there's a missing word. > > The retrieval protocol mechanism for semi-restricted and restricted > data needs a way for the receiver of the request to identify the > originator of the request and what is being requested. The receiver > of the request will process that request based on this information. > > 4.3.1. Retrieval of Public Data > > Eithert administrative or service data may be made publicly available "Either" > by the authority that generates and provisions it. Under most > circumstances, a CSP wants its communications service to be publicly > reachable through TNs, so the retrieval interface supports public > interfaces that permit clients to query for service data about a TN. > Some service data may however require that the client be authorized "...may, however, require..." > to receive it, per the use case in Section 4.3.3 below. > > Public data can simply be posted on websites or made available > through a publicly available API. Public data hosted by a CSP may > have a reference address at the Registry. > > 4.3.2. Retrieval of Semi-restricted Administrative Data > > Consider a case in which a CSP is having service problems completing > calls to a specific TN, so it wants to contact the CSP serving that > TN. The Registry authorizes the originating CSP to access this > information. It initiates a query to the Registry, the Registry "The CSP initiates a query to the Registry, and the Registry..." > verifies the requestor and the requested data and Registry responds "...data; the Registry responds..." > with the serving CSP and contact data. However, CSPs might not want > to make those administrative contact points public data: they are > willing to share them with other CSPs for troubleshooting purposes, > but not to make them available to general communication. > > Alternatively that information could be part of a distributed data "Alternatively, such information..." > store and not stored at a monolithic Registry. In that case, the CSP > has the data in a local distributed data store and it initiates the > query to the local data store. The local data store responds with > the CSP and contact data. No verification is necessary because it > was done when the CSP was authorized to receive the data store. > > 4.3.3. Retrieval of Semi-restricted Service Data > > Consider a case where a User on a CSP's network calls a TN. The CSP > initiates a query for service data associated with the TN to complete > the call, and will receive special service data because the CSP > operates in a closed environment where different CSPs receive > different responses, and only participating CSPs can initiate > communications. This service data would be flagged as semi- > restricted. The query and response have real-time performance > requirements in that environment. > > Semi-restricted service data also works in a distributed data store > model, where each CSP distributes its updated service data to all > other CSPs. The originating CSP has the service data in its local > data store and queries it. The local data store responds with the > service data. The service data in the response can be a reference > address to a data store maintained by the serving CSP, or it can be > the service address itself. In the case where the response gives a > reference address, a subsequent query would go to the serving CSP, > who would in turn authorize the requestor for the requested data and "...which would in turn..." > respond appropriate. In the case where the original response "...respond appropriately." > 7. Security Considerations > > ... > A management interface for telephone numbers has similar > requirements. Without proper authentication and authorization > mechanisms in place, an attack could use the management interface to "...an attacker could use..." > disrupt service data or administrative data, which could deny service > to users, enable new impersonation attacks, prevent billing systems > from operating properly, and cause similar system failures. > > Finally, a retrieval interfaces has its own needs for mutual "Finally, a retrieval interface has its own..." or "Finally, retrieval interfaces have their own..." > authentication, integrity protection, and for confidentiality. Any "...authentication, integrity protection, and confidentiality" or "authentication, for integrity protection, and for confidentiality" Thanks! /a From nobody Thu Feb 1 13:01:33 2018 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 8944012ECCB; Thu, 1 Feb 2018 13:01:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.71.0 Auto-Submitted: auto-generated Precedence: bulk CC: modern@ietf.org, draft-ietf-modern-problem-framework@ietf.org, adam@nostrum.com, modern-chairs@ietf.org, srdonovan@usdonovans.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151751888755.24420.14106388196883222788.idtracker@ietfa.amsl.com> Date: Thu, 01 Feb 2018 13:01:27 -0800 Archived-At: Subject: [Modern] Last Call: (Modern Problem Statement, Use Cases, and Framework) to Informational RFC X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.22 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, 01 Feb 2018 21:01:28 -0000 The IESG has received a request from the Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers WG (modern) to consider the following document: - 'Modern Problem Statement, Use Cases, and Framework' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-02-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-modern-problem-framework/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-modern-problem-framework/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Feb 6 19:03:05 2018 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 3DB6F120725; Tue, 6 Feb 2018 19:02:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: Cc: modern@ietf.org, draft-ietf-modern-problem-framework.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151797257117.25846.10939835643004143536@ietfa.amsl.com> Date: Tue, 06 Feb 2018 19:02:51 -0800 Archived-At: Subject: [Modern] Genart last call review of draft-ietf-modern-problem-framework-03 X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.22 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, 07 Feb 2018 03:02:51 -0000 Reviewer: Joel Halpern Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-modern-problem-framework-03 Reviewer: Joel Halpern Review Date: 2018-02-06 IETF LC End Date: 2018-02-15 IESG Telechat date: 2018-02-22 Summary: This document is ready for publication as an Informational RFC. Major issues: Minor issues: I presume that the lack of description on how to apply controls to semi-restricted or restricted data, particulalry in the distributed data store case, is deliberate? I presume that the WG intent is that this is a topic to be dealt with in the solutions, not the problem statement and framework? Things are fine if that is the intent. If the WG views this as an actual useful description of how to handle those aspects, then I would ask for more descriptions. Nits/editorial comments: Editorial: In the definition of Credential Authority the text uses the phrase "one of more" when I am pretty sure the intent is "one or more". From nobody Sun Feb 11 09:04:05 2018 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 EEFF81201F2; Sun, 11 Feb 2018 09:04:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: adam@nostrum.com, modern@ietf.org, smccammon@amsl.com, modern-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151836864393.17092.8109255074145924059.idtracker@ietfa.amsl.com> Date: Sun, 11 Feb 2018 09:04:03 -0800 Archived-At: Subject: [Modern] modern - New Meeting Session Request for IETF 101 X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Feb 2018 17:04:04 -0000 A new meeting session request has just been submitted by Stephanie McCammon, on behalf of the modern working group. --------------------------------------------------------- Working Group Name: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers Area Name: Applications and Real-Time Area Session Requester: Stephanie McCammon Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 40 Conflicts to Avoid: First Priority: dime dispatch sipcore stir Second Priority: mmusic People who must be present: Steve Donovan Adam Roach Tom McGarry Jon Peterson Chris Wendt Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Feb 12 13:48:49 2018 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 E3D0C12D86B; Mon, 12 Feb 2018 13:48:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Linda Dunbar To: Cc: modern@ietf.org, draft-ietf-modern-problem-framework.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151847211687.6022.3464641768771654781@ietfa.amsl.com> Date: Mon, 12 Feb 2018 13:48:36 -0800 Archived-At: Subject: [Modern] Opsdir last call review of draft-ietf-modern-problem-framework-03 X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 21:48:37 -0000 Reviewer: Linda Dunbar Review result: Has Issues The draft brought up a very interesting aspect of Telephone Numbers (TNs), especially the mobile phone number which is widely used for getting "secure code" for secure access to very sensitive content, such as bank account. However, the draft only describes how today's TNs are acquired and managed (e.g. the Use cases in Section 4). Two issues with the draft: 1) The draft didn't have the content to describe what is the problems with the current practices. (I was expecting to read the "problems" when I started to read the draft) 2) The draft didn't describe the problems of using mobile phone number for authenticating the access to sensitive data content. Linda dunbar From nobody Mon Feb 12 14:17:56 2018 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 47D181270AC; Mon, 12 Feb 2018 14:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 0vyVe2-V_HVC; Mon, 12 Feb 2018 14:17:43 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0097.outbound.protection.outlook.com [104.47.40.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D176E126D74; Mon, 12 Feb 2018 14:17:39 -0800 (PST) Received: from CO2PR05CA0066.namprd05.prod.outlook.com (10.166.88.162) by BN6PR05MB3586.namprd05.prod.outlook.com (10.174.234.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.7; Mon, 12 Feb 2018 22:17:37 +0000 Received: from BN3NAM01FT049.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e41::203) by CO2PR05CA0066.outlook.office365.com (2603:10b6:102:2::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.506.7 via Frontend Transport; Mon, 12 Feb 2018 22:17:37 +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 BN3NAM01FT049.mail.protection.outlook.com (10.152.66.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.444.13 via Frontend Transport; Mon, 12 Feb 2018 22:17:36 +0000 Received: from pps.filterd (preapdm2.corp.sprint.com [127.0.0.1]) by preapdm2.corp.sprint.com (8.16.0.21/8.16.0.21) with SMTP id w1CLYhAO025986; Mon, 12 Feb 2018 17:17:36 -0500 Received: from prewe13m03.ad.sprint.com (prewe13m03.corp.sprint.com [144.226.128.22]) by preapdm2.corp.sprint.com with ESMTP id 2g1u0e4p36-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 12 Feb 2018 17:17:36 -0500 Received: from PLSWE13M04.ad.sprint.com (2002:90e5:d617::90e5:d617) by PREWE13M03.ad.sprint.com (2002:90e2:8016::90e2:8016) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 12 Feb 2018 17:17:35 -0500 Received: from PLSWE13M04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a]) by plswe13m04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a%24]) with mapi id 15.00.1347.000; Mon, 12 Feb 2018 16:17:34 -0600 From: "Gorman, Pierce A [CTO]" To: Linda Dunbar , "ops-dir@ietf.org" CC: "draft-ietf-modern-problem-framework.all@ietf.org" , "modern@ietf.org" , "ietf@ietf.org" Thread-Topic: [Modern] Opsdir last call review of draft-ietf-modern-problem-framework-03 Thread-Index: AQHTpEtMcDne+zEoeUG2bh8tZbj/jqOhVXzw Date: Mon, 12 Feb 2018 22:17:34 +0000 Message-ID: References: <151847211687.6022.3464641768771654781@ietfa.amsl.com> In-Reply-To: <151847211687.6022.3464641768771654781@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.123.104.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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)(346002)(39380400002)(39860400002)(396003)(376002)(2980300002)(438002)(13464003)(189003)(199004)(186003)(86362001)(575784001)(47776003)(2950100002)(50466002)(24736004)(108616005)(102836004)(23726003)(356003)(316002)(54906003)(3846002)(26005)(97736004)(106466001)(46406003)(110136005)(7736002)(106002)(305945005)(5660300001)(6116002)(6246003)(4326008)(76176011)(81166006)(966005)(97756001)(336011)(59450400001)(53936002)(8746002)(6306002)(8936002)(14454004)(8676002)(81156014)(45080400002)(5250100002)(229853002)(478600001)(68736007)(72206003)(2501003)(7696005)(2900100001)(2906002)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR05MB3586; H:preapdm2.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN3NAM01FT049; 1:dsr+6mkY1e2Am7B/CnNG26rFiaPbbRvCGhKDKuNfcjyVJa9XnQZZYm0/Bde2MvlftyssF3fYPJF7INaLX3OPsJDfvA3melTPqzLmXgZFpFjJggNVF9nYo+A/aYildGQ7 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d763753f-3bbe-4de4-47b7-08d572666c36 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989060)(5600026)(4604075)(4608076)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603307)(7153060)(7193020); SRVR:BN6PR05MB3586; X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3586; 3:d6twsnU/Aq4CsNoyb/5C3NPIh/Dfm6IDeMFhbSvE/DpKiUQANs9tP8ObaeK5lSS56eM6SNoe0FimtH2MNwWT8jqzF7wxGb7JI5t5sDxrI4yMzbYj/IEj1FO1iXXSmbRo3z/y/niYY6NGs9WV58KMLwAyLz1Vc6lXcDxjIuBuTmbo49TB8hALsMdP6UrDVOpeFNtaaRp1HBiUkHeQ6FnZmJxdOYbHbEKCwp498WOD5K19d+mmg6Fro3475d/cN3lLKosGURupKpGSAwuBxdJ+VNxzdqIxO58MDQ67um69a3OfEOLjzgDuIanF2ciBr8n17GXHvS5nPlj40XjDu3HW+HHFin0OLOWQEoXoy1u0SJU=; 25:/WJHnApmwyDfR1GOYmuEOXcCukY39Q9YjX9jMI8hugW2hilPob0/V/ZOYYUXdonSccMgfcKXma3SJKNDS3pPNIVFHvMALcbXzHd7Slx1xEe7WRUITqJBGby6NXvlai1ZHSJQw1xzFyY9OQK/82u0S7Rz6bxSxk3QJvuXpLkzsU7ILqcfcyjsUwKlmmpx39hHGvj6M9R/I3nLQWdDVDiEZ77TxlsxaJuxD2RFCZmJ5rGDSJ/gvilx0cek2YzrVbw/YdUMqks8oeBZTXLpGW4dUmmjUJxVM9iJjzrrM1l3k5vwe+NNqCBEVn0/3R/maki262IvlDjX2hxwEeG+s3WtWg== X-MS-TrafficTypeDiagnostic: BN6PR05MB3586: X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3586; 31:DopM6tngpWhgQDnRgVlWBWIwFG3E7YVIdMVXEDgo2QzbEO9eqLhhuy9hozoFo1S+vXSyYusG+dpWCLSWsJTwFObMKBQmPSymdBI7MjPmgbbT+ZrWdgWpmQZbg3Ys5BI12oUbRcrZPad7PUT0l0cghf+hbJd9LQ2fuCNCepZGa0DiY7RpnzOk4bJnv+PmUZ7dQVkRpZHy5XwLTEei85E1DHT7wLBRxRx5xaiLPGfGCV8=; 20:72nxwRsC98pAmX5wnZiYZSt2BC0FDF4rg4x34d5KjyxW0xI6gK/DcMutAYgG0PJLKGseDxGG5YuH5GOkipqrEcTfiDBS5k9loExaKGUg0tHo7YCUHmlreLH82IRnXTE7RvxxZpa4PMEi/KQbq09idjhWglaoy/IESRLeudtVICCGYtHgrocHRL+ym6a1M3/FMx5JVqXBXc0U1+dba7leaFKOx2SCXpzCSl+kAbnQRAj+lIq2g02EU7Z7EysxceNtt5HQ0VkV2lb5evPB90M9g5KBChAuFK9eDe9lODpsekgLp47cOqtdod2QohufLZEZq1tQsC0l+MjaExvgQdPj40dLz+g5HXlRB0I8M1c8EpCZGMcHg4/dpfgt3EjLQu3XN0XJ66ZTWmda+dJ66caYQLcT/JvPnI1ZhOfpsKx0IJhqX34nqvAmu9T8zsGFf08oG0xAXLdcI0ymQKclyrTmdAekc1bv8yi+eMv3joJxH33KQ8PYfLEL2Q5/v0Hl69hR X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(189930954265078)(219752817060721); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(93006095)(93004095)(3231101)(2400082)(944501161)(10201501046)(6055026)(6041288)(20161123564045)(20161123562045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BN6PR05MB3586; BCL:0; PCL:0; RULEID:; SRVR:BN6PR05MB3586; X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3586; 4:FAJt4InYDoYJHOn+DeFOue+STtAtCwErWDnXAjXCffVuzJRRkohZtGq07v612ItLy/KFgwX6KHOK8w51MASDG8t21Crrd3ylBPhiwER2MRLs8PC0sqtfBynq5fsVJYa/b6+siZIrum7S5vxGGRxuYf1iFXu6euKFTOFBjaOrE3+VtuqDuHoJO2iFxJlI50om+kGeQdSsHPOP33FjayId0WolJWEz6ciyNLnq/O2JgTRsaLJjlhmZ9RW8A4ZTf4cEfTli8T0pfkMFdnq9f87omYA7BPGhqdELit+rjXjmfMmKwnYSveFdw97uuSIZqPWimC+1Q4Co5bZvNERie/axASlYHDhF/zOdNVX1KcrCgvA= X-Forefront-PRVS: 0581B5AB35 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN6PR05MB3586; 23:n7CFJ6I+HJcosRGjDwmAGwG/HZbQrhsA1H2RAVkIi?= =?us-ascii?Q?hd2MhLzgfNQE74G5KCS/Dy6dbivDJDeuPrEC7en7dHCQ2w6Tdgo4+VKSFLS/?= =?us-ascii?Q?LRoxjK7UsL6QtvvS+t+Ax5L2UmfnmSRhDnEvRJZxiWiA2GjiwH3tqkwFbky4?= =?us-ascii?Q?f2OgMZkMoDpVRVtHMX/YY3Bo+sYs5LyP/w4qd9QtlLBPmpm9sGvc0L+bqorp?= =?us-ascii?Q?qWceECB/l8G58+7jK5YA+vy+C3+3Z0CBFTPRCYHwNUNCXYHYrLNW44vXFaVw?= =?us-ascii?Q?1ZllpJldnaTjJ2O+odX0dh7cEhI6WimIFITfg+R2+/t8AdZzLvswxlGvNECL?= =?us-ascii?Q?hgWvKHPSgf793EyAN4WzLcDbJUNXVz7t3yT3Q1B7TP275WsQW7YmSExOs6ur?= =?us-ascii?Q?/YQwetFG/+qbCjpn20vXMXGEVc67nOHJzQqT+LWMuTlcgAKuIzK2azfXn8c0?= =?us-ascii?Q?GV46tsJ+NmapD2E/74gte9VyqQol8w9pdtChrYweeKJTkKdknsLcKMPtuzFd?= =?us-ascii?Q?WWgT4zT4Oeq27KuaKSuxHLiYyDOAahePrKBxUMedBG7m7Axf9AX57e6RUZGN?= =?us-ascii?Q?uryP3k7lMowKKBry61Khhy+lIWnbh814RSF6kZVpCXeo4PBN1266h9c1ST3U?= =?us-ascii?Q?IrUM676k1ay2/8ZV1qrlnzmvXo3X6+SeMQuvoB1L3MKXbitURIrFn6d/i0zK?= =?us-ascii?Q?0mLT9ikZrWHbLbwKY5qH0AI5OnpB/+oqkALdpBNUf5dPOEtOchvkiZdpBNjB?= =?us-ascii?Q?+Ulw1CwEblGIkm0VLANY/2lB8yCyZ8d/jDF6pw+BiL0/nmalpXUMuSs9VKQD?= =?us-ascii?Q?USK0ASBCy138dYQoFk1IPNIAqpNWYyW2lPkeSMaTfIfgLEn3x3mIJaX9asVv?= =?us-ascii?Q?M2t2vDaVEyM7E8dHjyKUINoDPkFSP0VTCxRgdgQ7JMZEQZ97GvynEUPejKkt?= =?us-ascii?Q?jGZty9noIeWnEQDbMKrzwtP5wft1SLjdILw3WisyTgsD/j6B5atRLXBZBvoK?= =?us-ascii?Q?9YzdwJe3vyMlwlTdVtCTvSnzu6j1s6FGpBLq+tokyw4I7CbHMXm5njpxn3wa?= =?us-ascii?Q?/01E/CjAs7bn4IV6lbNT3kITgl/cOxpXdZbBZvfpCqIgC1kOmLHPUkDobFQw?= =?us-ascii?Q?6/gbtozcPXHuYH7L8OFdS7bsnHxhBU2AAPcSeYfXkrQOasXquQ/QTJVMZce9?= =?us-ascii?Q?hcg3R63gnppIPA2TAMVw9JLQDoNutR03geAluFMmOnrfGn9ji7NqTKA3uPHH?= =?us-ascii?Q?E5HJZb9eDQMbr1be+mSgryDkRYHOa0kNsjreI771q0LmmlZpphjOIk5E3jln?= =?us-ascii?Q?azv7khjZduZHysmePd1FnN0cSo/Bryxralk432Nghj/bx9D4J/hrAkIEq6yQ?= =?us-ascii?Q?B4nRvkT1zNacSP9RNU4WDOM3FA=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3586; 6:5dJKMgHzPMQjfI/hfm3wOQ79KfXNJKdQKg182lsjNkaewCcfGmRcN43XuSmC5ymCbS96FgQLLRGjKFydKDrS/h/KJ5X3f6/R8d2kTYJJQNMemhHY4sCR0olbIudRoewaO/cEAe44Dw+vw0Oua0WO4abxHwSqLvI4I5WF+ck9I3mlqceaF1ziUxpC9xqb4GpyH2oNyvcr3agxrmIm1f8S5rtU3TMPTvSSScqKo9HHyznIvIcMBZHvGyB14arLAIjSzVi4q1Q4cvULaLBRtPWK/CMKUBIa1fxrlca7Z9fWtEeax4cix+7Nf3OSfvCtGwllOVEbH6w459gPguNzqMfV3ZS8/1i5xypNp8RGXEytBFg=; 5:Y1DgaB/GRjQ/4Ib2RWke31bXDpwZj9awrU9MDi0vF/4LD7yZ0kKy/bqPnuiQ0u0a2fX5FmjNny5OHG2IGmvCWLCcfPsQlyDtuAWEHNtdD6c1hMOSWd7A6+ZOENbt+BVB3FKYBDt1uoLlNQih3+MIBhe8TGgyHY8spyqmfusr2VA=; 24:BcjPHFUhlrSAsdX5HAjk483hiN2v/AAewezmC+swcxzEsGzIm95MDRjkUIaaL5mpwt9+C/QXX29IuGmzlDIgIJ/4BvbyyecYAQhjbO2/Np4=; 7:+pRpJ9ACIdCWD3KYOocQzvF6UGSknzTsTDEEGqsm+CGNSwdM9fSEVZAwvAG8hVpedZacV7Ea5Hh5D/d/hYPhvtsR12617t850a8PTpLeVAwnqzB8FSkdNFrEERtsvh9H4bnTqREe52iqGoLJTE+vkT3EpFDxE4scis9WLOROmOfO5shDd5q1CDQbQlVzjs71g4gYjpNncKMg+TjUlwk6eX/akXSIKxCSRhgLViC0Eo7be8HRvCqAoC166JEPfzV6 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Feb 2018 22:17:36.9895 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d763753f-3bbe-4de4-47b7-08d572666c36 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: BN6PR05MB3586 Archived-At: Subject: Re: [Modern] Opsdir last call review of draft-ietf-modern-problem-framework-03 X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 22:17:46 -0000 Linda, You are correct to be concerned that the draft did not have the content to = describe what is the problems with the current practices. I registered the same concern on January 10th of 2016. Pierce -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Monday, February 12, 2018 3:49 PM To: ops-dir@ietf.org Cc: draft-ietf-modern-problem-framework.all@ietf.org; modern@ietf.org; ietf= @ietf.org Subject: [Modern] Opsdir last call review of draft-ietf-modern-problem-fram= ework-03 Reviewer: Linda Dunbar Review result: Has Issues The draft brought up a very interesting aspect of Telephone Numbers (TNs), = especially the mobile phone number which is widely used for getting "secure= code" for secure access to very sensitive content, such as bank account. However, the draft only describes how today's TNs are acquired and managed = (e.g. the Use cases in Section 4). Two issues with the draft: 1) The draft = didn't have the content to describe what is the problems with the current p= ractices. (I was expecting to read the "problems" when I started to read th= e draft) 2) The draft didn't describe the problems of using mobile phone numb= er for authenticating the access to sensitive data content. Linda dunbar _______________________________________________ Modern mailing list Modern@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Fmodern&data=3D02%7C01%7Cpierce.gorman%40sprint.= com%7C7f8619cae5da417f1a5b08d572626cb2%7C4f8bc0acbd784bf5b55f1b31301d9adf%7= C0%7C0%7C636540689416937166&sdata=3D1nfaQf65bA1JWcubYVRammbDhM1GP7IafK9IbXi= K4bE%3D&reserved=3D0 ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Fri Feb 16 08:59:12 2018 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 175DE1270FC; Fri, 16 Feb 2018 08:59:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alvaro Retana To: "The IESG" Cc: draft-ietf-modern-problem-framework@ietf.org, modern-chairs@ietf.org, srdonovan@usdonovans.com, modern@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151880034804.1429.7842564021239285493.idtracker@ietfa.amsl.com> Date: Fri, 16 Feb 2018 08:59:08 -0800 Archived-At: Subject: [Modern] Alvaro Retana's No Objection on draft-ietf-modern-problem-framework-03: (with COMMENT) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.22 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, 16 Feb 2018 16:59:08 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-modern-problem-framework-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-modern-problem-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (0) For the benefit of non-modern readers, changing the title or at least making it clear that "modern" refers to an acronym, and later expanding and explaining would be very nice. (1) The document mentions the need for authentication, integrity and confidentiality when retrieving information. However, I didn't see anything related to verifying that in fact the CSP (for example) is the "proper authority" -- IOW, how can the user requesting information verify that the CSP is in fact the one responsible for the TN? I'm thinking of the case where the CSP was assigned a TN from the numbering authority (how is that verified?), and also the portability case (4.2.3.1) where the "old CSP" is no longer responsible for the user's service. Given that this document is a framework, I obviously don't expect a solution. But I think validation of the assignment chain should be included for consideration by future solutions. From nobody Fri Feb 16 11:21:51 2018 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 952E81200C1; Fri, 16 Feb 2018 11:21:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoav Nir To: Cc: modern@ietf.org, draft-ietf-modern-problem-framework.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151880889952.1465.16611057002784350280@ietfa.amsl.com> Date: Fri, 16 Feb 2018 11:21:39 -0800 Archived-At: Subject: [Modern] Secdir last call review of draft-ietf-modern-problem-framework-03 X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.22 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, 16 Feb 2018 19:21:42 -0000 Reviewer: Yoav Nir Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and others should treat these comments just like any other late last call comments. The document is well-written although it uses a lot of jargon without defining it first. For example: An increasing number of enterprises, over-the- top voice-over-IP (VoIP) providers VoIP I understand. What is over-the-top? Since the target audience is IETF people who are more well-versed in telephony jargon than I am, this is probably fine. What I didn't like about this is the introduction in section 1. It reads like a marketing document rather than a technical one. For example: The challenges of utilizing telephone numbers (TNs) on the Internet have been known for some time. It's only challenging if I want to use a TN on the Internet. Why do I want to do that? Thanks to the increasing sophistication of consumer mobile devices as Internet endpoints as well as telephones, users now associate TNs with many Internet applications other than telephony. So because my phone is so sophisticated and has IP, I now associate phone numbers with Internet applications? Why? The Security Considerations section is fine, but I think this is one draft that should have privacy considerations either as a separate section or as a paragraph in the Security Considerations section. It should be called out that the administrative data often contains PII - real names and addresses of users and the usage of phone numbers as identifiers on the Internet allows for mapping these real names and addresses to transactions on the Internet. I think this deserves a mention From nobody Tue Feb 20 07:27:08 2018 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 72CE81242F7; Tue, 20 Feb 2018 07:27:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-modern-problem-framework@ietf.org, modern-chairs@ietf.org, srdonovan@usdonovans.com, modern@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151914042242.4734.5909057515713299692.idtracker@ietfa.amsl.com> Date: Tue, 20 Feb 2018 07:27:02 -0800 Archived-At: Subject: [Modern] Alexey Melnikov's Yes on draft-ietf-modern-problem-framework-03: (with COMMENT) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 15:27:03 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-modern-problem-framework-03: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-modern-problem-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for a well written document. I am agreeing with Alvaro about expanding MODERN on first use. 4.2.1.2. Mangaing Data at a CSP Typo: Managing From nobody Wed Feb 21 08:36:58 2018 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 55E1B12D7F8; Wed, 21 Feb 2018 08:36:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-modern-problem-framework@ietf.org, modern-chairs@ietf.org, srdonovan@usdonovans.com, modern@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151923101230.9811.5144579847702047986.idtracker@ietfa.amsl.com> Date: Wed, 21 Feb 2018 08:36:52 -0800 Archived-At: Subject: [Modern] Eric Rescorla's No Objection on draft-ietf-modern-problem-framework-03: (with COMMENT) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.22 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, 21 Feb 2018 16:36:52 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-modern-problem-framework-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-modern-problem-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- from a Registrar. Today, a user wishing to acquire a freephone number may browse the existing inventory through one or more Registrars, comparing their prices and services. Each such Registrar what's a "freephone number" kept by the Registry, TNs assigned to a User are always considered assigned, not inventory.In this use case, after receiving a number assignment from the Registrar, a User will then obtain communications You said this above. Eithert administrative or service data may be made publicly available by the authority that generates and provisions it. Under most Nit: "Eitehr" have a means of authenticating the source of the query, and of protecting the integrity and confidentiality of its responses. Also, aren't there privacy type issues in the retrieval of the service data? I.e., I would assume we don't want random people to retrieve the service data associated with a TN. From nobody Wed Feb 21 14:29:37 2018 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 E7BA712422F; Wed, 21 Feb 2018 14:29:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-modern-problem-framework@ietf.org, modern-chairs@ietf.org, srdonovan@usdonovans.com, modern@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151925217190.21089.13908744069857239379.idtracker@ietfa.amsl.com> Date: Wed, 21 Feb 2018 14:29:31 -0800 Archived-At: Subject: [Modern] Kathleen Moriarty's No Objection on draft-ietf-modern-problem-framework-03: (with COMMENT) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.22 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, 21 Feb 2018 22:29:32 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-modern-problem-framework-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-modern-problem-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with the SecDir reviewer that a Privacy Considerations section is needed. I am not finished reading the draft and may move this to a discuss after doing so. It's a well written draft, this appears to be a gap and I didn't see a response to the SecDir review. https://mailarchive.ietf.org/arch/msg/secdir/1WiFmubNoAKo3qAhNu4be35g10w From nobody Wed Feb 21 18:51:16 2018 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 0D74B128959; Wed, 21 Feb 2018 18:51:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-modern-problem-framework@ietf.org, modern-chairs@ietf.org, srdonovan@usdonovans.com, modern@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151926787492.21271.961401229922724643.idtracker@ietfa.amsl.com> Date: Wed, 21 Feb 2018 18:51:14 -0800 Archived-At: Subject: [Modern] Kathleen Moriarty's Discuss on draft-ietf-modern-problem-framework-03: (with DISCUSS and COMMENT) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.22 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, 22 Feb 2018 02:51:15 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-modern-problem-framework-03: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-modern-problem-framework/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I agree with the SecDir reviewer that a Privacy Considerations section is needed. What user data is potentially exposed? 4.3.4 talks about government access, who else has access? What concerns are there about the data that is shared? What if one of the involved systems is compromised and data is stolen? It's a well written draft, this appears to be a gap and I didn't see a response to the SecDir review. Thanks in advance. https://mailarchive.ietf.org/arch/msg/secdir/1WiFmubNoAKo3qAhNu4be35g10w ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm a little surprised to see section 4.3.4 instead of just a statement on how authorized access to the data is provided. From nobody Wed Feb 21 19:06:26 2018 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 58F1712008A; Wed, 21 Feb 2018 19:06:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-modern-problem-framework@ietf.org, modern-chairs@ietf.org, srdonovan@usdonovans.com, modern@ietf.org, ldunbar@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151926877229.21173.17129022531942164328.idtracker@ietfa.amsl.com> Date: Wed, 21 Feb 2018 19:06:12 -0800 Archived-At: Subject: [Modern] Benoit Claise's No Objection on draft-ietf-modern-problem-framework-03: (with COMMENT) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.22 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, 22 Feb 2018 03:06:20 -0000 Benoit Claise has entered the following ballot position for draft-ietf-modern-problem-framework-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-modern-problem-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- >From Linda Dunbar, as OPS DIR reviewer: The draft brought up a very interesting aspect of Telephone Numbers (TNs), especially the mobile phone number which is widely used for getting "secure code" for secure access to very sensitive content, such as bank account. However, the draft only describes how today's TNs are acquired and managed (e.g. the Use cases in Section 4). Two issues with the draft: 1) The draft didn't have the content to describe what is the problems with the current practices. (I was expecting to read the "problems" when I started to read the draft) 2) The draft didn't describe the problems of using mobile phone number for authenticating the access to sensitive data content. From nobody Wed Feb 21 19:44:18 2018 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 B1A5E1204DA; Wed, 21 Feb 2018 19:44:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-modern-problem-framework@ietf.org, modern-chairs@ietf.org, srdonovan@usdonovans.com, modern@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151927105368.21093.5645217107118270013.idtracker@ietfa.amsl.com> Date: Wed, 21 Feb 2018 19:44:13 -0800 Archived-At: Subject: [Modern] Ben Campbell's Yes on draft-ietf-modern-problem-framework-03: (with COMMENT) X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.22 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, 22 Feb 2018 03:44:14 -0000 Ben Campbell has entered the following ballot position for draft-ietf-modern-problem-framework-03: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-modern-problem-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am balloting yes, but I do have a few minor comments: Substantive: §1: "An enterprise, for example, can deploy an IP PBX that receives a block of telephone numbers from a carrier and then in turn distribute those numbers to new IP telephones when they associate with the PBX. " That's been true for PBX's since well before the advent of IP PBXs. §2.1, Numbering Authority: "A regulatory body within a country" I suspect "country" should be "region", since the definition goes on to consider non-country domains. Editorial and Nits: §2.1, last paragraph (before figure): "and it issues 10,000 blocks of TNs to CSPs" Should that be "10,000 blocks" or "blocks of 10,000 TNs"? §4.1.1: Please define "freephone". Last paragraph: "... not inventory.In ..." Missing space after period. §4.2.3.1: " In a similar model to common practice in some environments today..." Should that be a "model similar to common practice"? §4.3, 2nd to last paragraph: The paragraph seems to end mid-sentence. §4.3.1: s/ Eithert / Either From nobody Wed Feb 21 21:41:34 2018 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 EE52A124D68; Wed, 21 Feb 2018 21:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=h6wBtzW7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JOFdGT7+ 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 V79lHnmFJM0R; Wed, 21 Feb 2018 21:41:26 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 493E8126FB3; Wed, 21 Feb 2018 21:41:26 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id ACCC921396; Thu, 22 Feb 2018 00:41:25 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Thu, 22 Feb 2018 00:41:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=/9SsPqkFwQf9nxF+yBUvGtaoqrDNx Pi4cl7KvBSR6Hs=; b=h6wBtzW7X+cvyggIaY9LP/f9sCgW/6VRw9gfl/AjL6Eoc qL7j6cw2z4wVJmLBNlUlunrLXMEpv5dPOnrUHuJTv1i66xJX5+pXux/O1mFlpwjf 4aJK/SmpybcuKqlN2xmq66VbpCXK7qyXH1Q5FUsYbVnQQ6Sgfxb0HBtDc5UIheVW sT9iAfjbc0pW+smJ+qHAxAF3KCuDLZvR20499l0Vhgsm+JmZDPDbzGdv/3hToLd8 oAc9ZJHDUMmHGn0JDrBuJ0SQxjU+7bmgduM2tAYKYq1/cS7PhVxP9h8py80M7MKZ FPpoKCi2P4aVEhcRfalTUPggBy0JYqB/IDYldduuw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=/9SsPq kFwQf9nxF+yBUvGtaoqrDNxPi4cl7KvBSR6Hs=; b=JOFdGT7+UwQY9uVrMVGdeR /WX6q+BYxu90uQ3PuYTEbrBNefDJF50ssfW0t+vgJXe1Jg66t+v49JfutU/UaIrT zlaG9j6BeCySpm5L4pjDbfKGykLs5CTk74fze5qGW7Id8pBI1xgU6BMZjvbvasYp mGyRnOybaY+cYUJG2GscC2cAXE0k8wwZgu14vhukqiS8fQ47QJS+g9C/zYTfWdNB pdpCimRRBm6pRPyosqg54xND5exTU8AtNy8ATpvXChcEBGTwoiX7Tz0mzdTSJdVm CLxT9wjEQ/gLRVhDUmb4a4HdgNa6RetZi8O5iL4wKghFk9SQiMJVFHOKO+CDGryQ == X-ME-Sender: Received: from [10.19.234.245] (unknown [128.107.241.191]) by mail.messagingengine.com (Postfix) with ESMTPA id A907924108; Thu, 22 Feb 2018 00:41:24 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <151797257117.25846.10939835643004143536@ietfa.amsl.com> Date: Wed, 21 Feb 2018 21:41:23 -0800 Cc: General Area Review Team , draft-ietf-modern-problem-framework.all@ietf.org, modern@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <570C6A65-6BD5-4FA1-8FC2-EB4AEE929F13@cooperw.in> References: <151797257117.25846.10939835643004143536@ietfa.amsl.com> To: Joel Halpern X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Modern] [Gen-art] Genart last call review of draft-ietf-modern-problem-framework-03 X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.22 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, 22 Feb 2018 05:41:28 -0000 Joel, thanks for your review. I suspect the controls you=E2=80=99re = contemplating are in fact solution-dependent. I entered a Yes ballot - glad to see this bit of work concluding. Alissa > On Feb 6, 2018, at 7:02 PM, Joel Halpern wrote: >=20 > Reviewer: Joel Halpern > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-modern-problem-framework-03 > Reviewer: Joel Halpern > Review Date: 2018-02-06 > IETF LC End Date: 2018-02-15 > IESG Telechat date: 2018-02-22 >=20 > Summary: This document is ready for publication as an Informational = RFC. >=20 > Major issues: >=20 > Minor issues: > I presume that the lack of description on how to apply controls to > semi-restricted or restricted data, particulalry in the distributed = data > store case, is deliberate? I presume that the WG intent is that = this is a > topic to be dealt with in the solutions, not the problem statement = and > framework? Things are fine if that is the intent. If the WG views = this as > an actual useful description of how to handle those aspects, then I = would > ask for more descriptions. >=20 > Nits/editorial comments: > Editorial: In the definition of Credential Authority the text uses = the > phrase "one of more" when I am pretty sure the intent is "one or = more". >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue Feb 27 15:21:57 2018 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 9011912EB80; Tue, 27 Feb 2018 15:11:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: adam@nostrum.com, modern@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151977308858.5200.8669739904776183661.idtracker@ietfa.amsl.com> Date: Tue, 27 Feb 2018 15:11:28 -0800 Archived-At: Subject: [Modern] modern - Requested session has been scheduled for IETF 101 X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 23:11:29 -0000 Dear Stephanie McCammon, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. modern Session 1 (1:00:00) Monday, Morning Session I 0930-1200 Room Name: Blenheim size: 200 --------------------------------------------- Special Note: 1100-1200 Request Information: --------------------------------------------------------- Working Group Name: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers Area Name: Applications and Real-Time Area Session Requester: Stephanie McCammon Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 40 Conflicts to Avoid: First Priority: stir sipcore dispatch dime Second Priority: mmusic People who must be present: Adam Roach Steve Donovan Chris Wendt Jon Peterson Tom McGarry Resources Requested: Special Requests: ---------------------------------------------------------