From nobody Thu Mar 1 06:51:10 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 4AC2B129C51; Thu, 1 Mar 2018 06:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=team.neustar 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 2RtLZ1jlksK9; Thu, 1 Mar 2018 06:50:58 -0800 (PST) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D82C3129502; Thu, 1 Mar 2018 06:50:57 -0800 (PST) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w21Ei398032273; Thu, 1 Mar 2018 09:50:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.neustar; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=selector1; bh=LJNpnZh03RZC+JR9uhXpqTTlRlzaxUnGWE1btsBCJPg=; b=KrdurY9rOk3dkHFlBvnTet9OIGOs6pkOq89ZSvzi8SwTcmYfQCieoeOXE6z3gO1KHElf EtAi3Um/9I7uDPq4XBhu7QAlt3wc3Hr3TC5Zlt9eMCGsyDUlTOfzkI1ecPrC+NJyEI1/ 2Ht1XasjtR35fv2X43xi5rd8sGZc+Uvk4Ge6CLuAoJsMScE2vuWyM25HaUDHIFcwnk5Z jPBZUTTd/1FDOPwM4L0Qu+BCzrSI7JovaI0sxpaM/A7g+5XEZiq4yR0wZgGjDprBuD+P qlnz3mbDfH5kHnB7pITdb7hy0hIdW8rBvRnzKjaTEV0n8sa2jtn0MiqsHzDttO2Qabe6 Uw== Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 2gdqft9yqw-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 01 Mar 2018 09:50:54 -0500 Received: from STNTEXMB11.cis.neustar.com ([169.254.1.236]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 1 Mar 2018 09:50:54 -0500 From: "Peterson, Jon" To: Kathleen Moriarty , The IESG CC: "draft-ietf-modern-problem-framework@ietf.org" , "modern-chairs@ietf.org" , "srdonovan@usdonovans.com" , "modern@ietf.org" , Yoav Nir Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-modern-problem-framework-03: (with DISCUSS and COMMENT) Thread-Index: AQHTsWyyOrrLEbVdzECESvoi48YWjg== Date: Thu, 1 Mar 2018 14:50:53 +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.3.160329 x-originating-ip: [10.96.12.153] Content-Type: text/plain; charset="us-ascii" Content-ID: <944C3885D538614186507F66D06F4199@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-01_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803010186 Archived-At: Subject: Re: [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 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 Mar 2018 14:50:59 -0000 Hi Kathleen (and Yoav), We can certainly add a privacy considerations section to the document. Basically, I think it could read: -- This framework defines two categories of information about telephone numbers: service data and administrative data. Service data describes how identifiers map to particular services and devices that provide real-time communication services to users. As such, service data could potential leak resource locations and even lower-layer network address associated with these services, and in rare cases with end user devices. Administrative data more broadly characterizes who the administrative entities are behind identifiers, which will often identify service provides, but in some layers of the architecture could include personally identifying information, even WHOIS-style information, about the users behind identifiers. This could conceivably encompass the sorts of data that carriers and similar service providers today keep about their customers for billing purposes: real names and addresses, and similar personally identifying information. The exact nature of that information is not defined by this framework, and it is anticipated that the protocols that will perform this function will be extensible for different use cases, so at this point, it is difficult to characterize exactly how much PII might end up being housed by these services. As such, if an attacker were to compromise the registrar services in this architecture which maintain administrative data, and in some cases even service data, this could leak personally identifying information about end users. These interfaces, and the systems the host them, are a potentially attractive target for hackers and need to be hardened accordingly. Protocols that are selected to fulfill these functions must provide the security features described in [Sec Cons]. Finally, this framework recognizes that in many jurisdictions, certain government agencies have a legal right to access service and administrative data maintained by carriers. This access is typically aimed at identifying the users behind communications identifiers in order to enforce regulatory policy. Those legal entities already have this power to access the existing data held by carriers in many jurisdictions, though potentially the administrative data associated with this framework could be richer information. -- Would roughly that work? If so, will patch it in before the cut-off. Also, regarding 4.3.4, we really are trying not to sweep under the rug that government access is a use case for this framework. Just including this under the general idea that you need to be authorized to access information at these services would downplay the reality on the ground about Gov Entities and their relationship to the whole numbering ecosystem. On balance I thought it was better to be up front about it, And Yoav, we will also expand some of the early language in the document to make sure that terms like "over-the-top" are clear. Thanks! Jon Peterson Neustar, Inc. On 2/21/18, 6:51 PM, "Kathleen Moriarty" wrote: >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 Thu Mar 1 07:30: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 4FC5A12D93E; Thu, 1 Mar 2018 07:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=team.neustar 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 tSeP0naXHLeH; Thu, 1 Mar 2018 07:30:22 -0800 (PST) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB1BA12D943; Thu, 1 Mar 2018 07:30:22 -0800 (PST) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w21FPaqE001615; Thu, 1 Mar 2018 10:30:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.neustar; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=selector1; bh=9nQ7bD8eSPntodCm0WA6zjiuiupwYxEgDw/UqVjkfF8=; b=l+fyuSC2tm1WBki7AxZw2UaPLREcDUuGk9cmZi4NN1GzPtiXQ3MzGLdHlH3yZuU1rsNB K1ZAzOgjoY2ztt1kGCe8kqm/JEImCOle78NVaLAITpo3C5scEZ0g/5oiT2s38RlWAFKM rvf+FhawhCi1nyf6hzC4n24w+NwyKVS7SnJCHZtMjUCIbCS4EFUWEF92007hqYe70jJ9 NpaBQqYPl3Jq7matQNO3gj2CNjF/msRNH2IO9SQnbLGvgrg4/LczOQRoqeZANCvzHMMQ UVacuX9YM5RFhHSA5qWczeWs2rvYqOdnKM8MplzX+nF27v0RI3s+SntW5izI+4Jp3b+K 3w== Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 2gdqfujch2-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 01 Mar 2018 10:30:18 -0500 Received: from STNTEXMB11.cis.neustar.com ([169.254.1.236]) by stntexhc10.cis.neustar.com ([10.31.58.69]) with mapi id 14.03.0279.002; Thu, 1 Mar 2018 10:30:16 -0500 From: "Peterson, Jon" To: Benoit Claise , The IESG CC: "draft-ietf-modern-problem-framework@ietf.org" , "modern-chairs@ietf.org" , "srdonovan@usdonovans.com" , "modern@ietf.org" , "ldunbar@huawei.com" Thread-Topic: Benoit Claise's No Objection on draft-ietf-modern-problem-framework-03: (with COMMENT) Thread-Index: AQHTsXIzqUyxKmHYKU20VDEyVM+ENg== Date: Thu, 1 Mar 2018 15:30:16 +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.3.160329 x-originating-ip: [10.96.12.153] Content-Type: text/plain; charset="us-ascii" Content-ID: <842D9BBE527AAB4493953D7E688737E1@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-01_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803010193 Archived-At: Subject: Re: [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 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 Mar 2018 15:30:24 -0000 Hey Benoit (and Linda), I did want to make sure we addressed the review here. To the first question, I think we are trying to tee up what the problem is in the "problem statement" section. Broadly, there is a transition going on, for various economic reasons, that is pushing the telephone network off of its legacy infrastructure and on to the Internet. In so far as people still want to use telephone numbers for those services - and they do - we need a story about how to manage and resolve them. We've been trying to figure this out for years, but the attempt in MODERN is the first to kind of view this from a lifecycle perspective, where we use common objects to provision and resolve telephone numbers, and to build in the security lessons of STIR. Effectively we talk about ENUM and DRINKS in the first paragraph of the problem statement to tee up our discussion of why existing approaches aren't working. To the second question, I think the use of mobile phones as a form of two-factor auth isn't quite in the scope of this framework, except indirectly, in so far as routing decisions to mobile phones could be made through the retrieval interface in the document. I would say that more broadly, we hope that the credentials that will be installed in devices could take the place of those sorts of return-routability checks, but that depends more on work happening in ACME and STIR than here in MODERN. MODERN as a framework does draw the high-level picture of how those credentials might be provisioned as a part of acquiring those numbers. Does that make sense? Thanks! Jon Peterson Neustar, Inc. On 2/21/18, 7:06 PM, "Benoit Claise" wrote: >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 Thu Mar 1 07:54:50 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 98B9D12EA67; Thu, 1 Mar 2018 07:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=gmail.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 iSx7Ber7U7oD; Thu, 1 Mar 2018 07:54:32 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 70CE612EB08; Thu, 1 Mar 2018 07:54:32 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id c12so4805161oic.7; Thu, 01 Mar 2018 07:54:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JYirwA2fP0h9p6NdpxNqqnsZqqTFrtFggkg2Dl3VYGA=; b=MXq9lZxi+Wj5zzHXsAQJI4T3VujsDbQ+53LdWpTng1OkqkqZZzqQfjm/G4JoltY07L eunlHVk2Act4yAqHv6y9c02MNgzQ81RLNeDI06jpysrTqP8uL8u2ZnKQyNRLnvMq0LLL H/ZAnaE5du874SEGXvxpOYLutPtHrP2GdvjKtpuMkmiEuweymdWEHktm66LA8xSsWntq S0R6K1qskKtMjrfjnIpXmbpTste3YJyfJBcImPExGQniVb9+spVfXaC6KQiytTOlnOkR 2l/eIFXF1lUgFfbILTeYcUCGdlkSnp3glokqWP5JPtZ0WBixLdIMhLZvo5cieDxyq+ac IeXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JYirwA2fP0h9p6NdpxNqqnsZqqTFrtFggkg2Dl3VYGA=; b=nwoj7+JRe4Az1dMKce+DiMmvnx4ZV3YOgXBHlPgE+er1XpNTyt3ZzmSH+HHj8o3WY9 rvGbVPiTiu3+IQQzV2dtM/i81bclqgIu+IFJcbXm9mG8KdNUAty5leUKFR3SHmkS2twL 7BmXaBZlG+p3ln0KGu1H72Y/RwPRnlKhUAFLdJ5vx4k7JZC8bsy78upALVuNTFjaZzQ2 ZeH1Ne8do2N751TYekeopWQo7/dQFPoWTE0mfKc4MJkcO3HV7aXe2JrgLVoz2Hw6czmT DTqovSph5Pf/X7/5+FSDGo4ihH6HldcaEz3iGVUuWCqPHxPN6XZWXOf+YI8nJkj6rDkc sz/A== X-Gm-Message-State: AElRT7F/X3l16lb9wB91o4if+qEkNgGkaGdka+mPo2A/13uIBMie2+6+ vCiMsnQSd2oFCrK36PirvJ8I7bKbRvS24L7vGyI= X-Google-Smtp-Source: AG47ELsdHilmorD6O+oPgOXSy47FMXCKxZ+dvCJ1pvUcPGKPPNwWu7lOvdlqyi2FV1/xJOGluTtFXTjPyql/ykyBwf0= X-Received: by 10.202.177.2 with SMTP id a2mr1528484oif.175.1519919671587; Thu, 01 Mar 2018 07:54:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.46.119 with HTTP; Thu, 1 Mar 2018 07:53:51 -0800 (PST) In-Reply-To: References: From: Kathleen Moriarty Date: Thu, 1 Mar 2018 10:53:51 -0500 Message-ID: To: "Peterson, Jon" Cc: The IESG , "draft-ietf-modern-problem-framework@ietf.org" , "modern-chairs@ietf.org" , "srdonovan@usdonovans.com" , "modern@ietf.org" , Yoav Nir Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [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 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 Mar 2018 15:54:44 -0000 Hi Jon, On Thu, Mar 1, 2018 at 9:50 AM, Peterson, Jon wrote: > > Hi Kathleen (and Yoav), > > We can certainly add a privacy considerations section to the document. > Basically, I think it could read: > > -- > > This framework defines two categories of information about telephone > numbers: service data and administrative data. Service data describes how > identifiers map to particular services and devices that provide real-time > communication services to users. As such, service data could potential > leak resource locations and even lower-layer network address associated > with these services, and in rare cases with end user devices. > Administrative data more broadly characterizes who the administrative > entities are behind identifiers, which will often identify service > provides, but in some layers of the architecture could include personally > identifying information, even WHOIS-style information, about the users > behind identifiers. This could conceivably encompass the sorts of data > that carriers and similar service providers today keep about their > customers for billing purposes: real names and addresses, and similar > personally identifying information. The exact nature of that information > is not defined by this framework, and it is anticipated that the protocols > that will perform this function will be extensible for different use > cases, so at this point, it is difficult to characterize exactly how much > PII might end up being housed by these services. > > As such, if an attacker were to compromise the registrar services in this > architecture which maintain administrative data, and in some cases even > service data, this could leak personally identifying information about end > users. These interfaces, and the systems the host them, are a potentially > attractive target for hackers and need to be hardened accordingly. > Protocols that are selected to fulfill these functions must provide the > security features described in [Sec Cons]. > > Finally, this framework recognizes that in many jurisdictions, certain > government agencies have a legal right to access service and > administrative data maintained by carriers. This access is typically aimed > at identifying the users behind communications identifiers in order to > enforce regulatory policy. Those legal entities already have this power to > access the existing data held by carriers in many jurisdictions, though > potentially the administrative data associated with this framework could > be richer information. > > -- > > Would roughly that work? If so, will patch it in before the cut-off. Yes, thank you. This text is very helpful. > > Also, regarding 4.3.4, we really are trying not to sweep under the rug > that government access is a use case for this framework. Just including > this under the general idea that you need to be authorized to access > information at these services would downplay the reality on the ground > about Gov Entities and their relationship to the whole numbering > ecosystem. On balance I thought it was better to be up front about it, So I agree, but the general point may be good to add as well. The IETF doesn't design protocols to aid surveillance, but the added text in the privacy section is helpful to point out that this is already done and would be done with or without this section pointing it out. > > And Yoav, we will also expand some of the early language in the document > to make sure that terms like "over-the-top" are clear. > > Thanks! > > Jon Peterson > Neustar, Inc. Thank you! Kathleen > > On 2/21/18, 6:51 PM, "Kathleen Moriarty" > wrote: > >>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. >> >> > -- Best regards, Kathleen From nobody Thu Mar 1 09:25:37 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 6DD8812EB9B; Thu, 1 Mar 2018 09:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=team.neustar 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 ueH3tdE1h_Fl; Thu, 1 Mar 2018 09:25:25 -0800 (PST) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D605512EAC1; Thu, 1 Mar 2018 09:25:25 -0800 (PST) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w21HPLuM020167; Thu, 1 Mar 2018 12:25:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.neustar; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=selector1; bh=Gtgf5nJh8WsPidPAS91RJ8LzHWNczJ/5i4/7Ugo3cH0=; b=IvsRdkIO4Wo+iQDKPqXczQF4xbj+hxyrMfZj0yBtyHN3933Emvzp+pHxKEX3JP1pOjpo 2QL2kN59+uRCI0rlc2ZZ5Gm12KIbt3/pZY1j75962M7SCFKvMEaIZldQykIZgtxIDxyX b45CU5tl35RxG14q+6T+MfTfIusXNONJyL2UcJlww+c1efKBPk3m1mzR3FqLEPH4Di3E HzPQVD+REVpAO3+UYqt4hyVPRVikkkq9sy9ywwQUTEBkOsMQPZGQwcveaB/KaJ/0/ZMA 8xJt4ogfcd+Oj+kubvb34oj2qWHa+rUar9ZACk+kXM50cFNoKmat8ag9ZxR0NDlCamRK sA== Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 2gdqfujjd2-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 01 Mar 2018 12:25:23 -0500 Received: from STNTEXMB11.cis.neustar.com ([169.254.1.236]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 1 Mar 2018 12:25:22 -0500 From: "Peterson, Jon" To: Alvaro Retana , The IESG CC: "draft-ietf-modern-problem-framework@ietf.org" , "modern-chairs@ietf.org" , "srdonovan@usdonovans.com" , "modern@ietf.org" Thread-Topic: Alvaro Retana's No Objection on draft-ietf-modern-problem-framework-03: (with COMMENT) Thread-Index: AQHTsYJHb5XX8y/T40mEmWGHOUqmKQ== Date: Thu, 1 Mar 2018 17:25:22 +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.3.160329 x-originating-ip: [10.96.12.153] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-01_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803010215 Archived-At: Subject: Re: [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 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 Mar 2018 17:25:27 -0000 Hi Alvaro, So, establishing which CSP is responsible for a given number today, in traditional PSTN operations in the USA at least, is done by consulting industry databases. Like, a national regulator delegates number blocks down to registries which maintain databases for the industry, basically, and CSPs then go to the registry to acquire number blocks, which they in turn dole out to consumers. So when a CSP places a call to a number, they query one or more of these industry databases that track how blocks and individual numbers are delegated in order to figure out how to get to the destination TN.=20 What we intend here is to replicate those delegation structures with a PKI. In other words, a CSP will have a credential (a la STIR) which shows that they are the property authority for the number block that contains a given number. Most of that protocol work is done over in STIR (see RFC8226, say); MODERN is really just providing a framework that includes that basic concept. Validation of the assignment chain is really a job for STIR. Does that help? Jon Peterson Neustar, Inc. On 2/16/18, 8:59 AM, "Alvaro Retana" wrote: >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.=20 >But I think validation of the assignment chain should be included for >consideration by future solutions. > > From nobody Mon Mar 5 10:44:31 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 D762C12E037 for ; Mon, 5 Mar 2018 10:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 Hd4NFAdtsSnR for ; Mon, 5 Mar 2018 10:44:28 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) (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 C54A612E895 for ; Mon, 5 Mar 2018 10:44:25 -0800 (PST) Received: from [97.99.50.102] (port=51115 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1esv5w-00292P-8R for modern@ietf.org; Mon, 05 Mar 2018 10:44:25 -0800 To: "modern@ietf.org" From: Steve Donovan Message-ID: Date: Mon, 5 Mar 2018 12:44:17 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [Modern] MODERN session at IETF 101 in London 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, 05 Mar 2018 18:44:29 -0000 All, We have an hour slot in London immediately following the DISPATCH session during the first slot on Monday morning. Please let Tom and I know about any agenda requests for this session. Regards, Steve From nobody Mon Mar 5 14:59:42 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 0E05E12EAE9; Mon, 5 Mar 2018 14:59:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: modern@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.74.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152029076900.12707.9418166237495276785@ietfa.amsl.com> Date: Mon, 05 Mar 2018 14:59:29 -0800 Archived-At: Subject: [Modern] I-D Action: draft-ietf-modern-problem-framework-04.txt 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, 05 Mar 2018 22:59:31 -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 WG of the IETF. Title : Modern Problem Statement, Use Cases, and Framework Authors : Jon Peterson Tom McGarry Filename : draft-ietf-modern-problem-framework-04.txt Pages : 24 Date : 2018-03-05 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-modern-problem-framework-04 https://datatracker.ietf.org/doc/html/draft-ietf-modern-problem-framework-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-modern-problem-framework-04 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 Thu Mar 8 06:55:14 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 8D1B41241F8 for ; Thu, 8 Mar 2018 06:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=team.neustar 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 mNTzAmB4WQFG for ; Thu, 8 Mar 2018 06:55:12 -0800 (PST) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6D2712DA24 for ; Thu, 8 Mar 2018 06:55:10 -0800 (PST) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w28ErfMt013043; Thu, 8 Mar 2018 09:55:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.neustar; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=selector1; bh=0TSuuWVHr0ciCpEDo8+LqzbcdEbiwFdFK0Y3OzBKHgw=; b=G+Xds7vOmF6unPjJvQ1clHflXzH/1BFKPlCDNoifNsW2+gWTT/xJOp29V+6z34GIpxI6 5WeZN2/xZEdQ7hLnfDRgBzGq82p68q/X6I1s/evfR+l0tS3HoFtvsAsYVAu0e/EhhFpF /e3CIGCEu4N2xQgpX+GL9FQUVkbXQkrHEFOSPxRyOAqBpGibvmFki59NvuITg3AzZ0ms YNCnhvuWopi+Q1vIugCARHJVxUTjZvtT7et0qonX224dyRmfrI+4j1Z4RIvSUerMORgI +CSPBm7ktR+hjJMDJwwXtDmGaEeIC5xZunkhawyOppcAdFikrJd2OfzkRcmb9VQxy5ok lA== Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 2gfrjpfn4v-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 08 Mar 2018 09:55:09 -0500 Received: from STNTEXMB11.cis.neustar.com ([169.254.1.236]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 8 Mar 2018 09:55:09 -0500 From: "Peterson, Jon" To: Steve Donovan , "modern@ietf.org" Thread-Topic: [Modern] MODERN session at IETF 101 in London Thread-Index: AQHTtu1zjsRFHY+C0UGt/NfpQNMMBQ== Date: Thu, 8 Mar 2018 14:55:08 +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.3.160329 x-originating-ip: [10.96.12.91] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-08_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803080174 Archived-At: Subject: Re: [Modern] MODERN session at IETF 101 in London 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, 08 Mar 2018 14:55:14 -0000 So we do have a few new and revised documents for MODERN that we might discuss this time. Last time we showed some early thinking about how TeRI and DRiP might play together. We decided to explore that a bit more deeply in a new draft: https://www.ietf.org/id/draft-peterson-modern-drip-teri-00.txt Probably we should focus most of our time around that. I did slightly update the base TeRI draft as well to reflect how the operations of MODERN are geared more towards centralized than decentralized architectures, and what the delta might be for a decentralized implementation of TeRI. We might also want to review the last-minute changes made to the MODERN problem statement and framework, such as the addition of the Privacy Considerations. Thanks! Jon Peterson Neustar, Inc. On 3/5/18, 10:44 AM, "Modern on behalf of Steve Donovan" wrote: >All, > >We have an hour slot in London immediately following the DISPATCH >session during the first slot on Monday morning. > >Please let Tom and I know about any agenda requests for this session. > >Regards, > >Steve > >_______________________________________________ >Modern mailing list >Modern@ietf.org From nobody Wed Mar 14 11:45:45 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 1B387126DED; Wed, 14 Mar 2018 11:45:44 -0700 (PDT) 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.75.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152105314408.25173.12887634174082111996.idtracker@ietfa.amsl.com> Date: Wed, 14 Mar 2018 11:45:44 -0700 Archived-At: Subject: [Modern] Kathleen Moriarty's No Objection on draft-ietf-modern-problem-framework-04: (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, 14 Mar 2018 18:45:44 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-modern-problem-framework-04: 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: ---------------------------------------------------------------------- Thanks for adding the privacy considerations section in response to my prior discuss. From nobody Thu Mar 15 23:30:01 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 BE0CF124B18; Thu, 15 Mar 2018 23:29:49 -0700 (PDT) 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.75.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , adam@nostrum.com, srdonovan@usdonovans.com, modern@ietf.org, modern-chairs@ietf.org, draft-ietf-modern-problem-framework@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <152118178973.4442.5916379739109520281.idtracker@ietfa.amsl.com> Date: Thu, 15 Mar 2018 23:29:49 -0700 Archived-At: Subject: [Modern] Document Action: 'Modern Problem Statement, Use Cases, and Framework' to Informational RFC (draft-ietf-modern-problem-framework-04.txt) 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 Mar 2018 06:29:50 -0000 The IESG has approved the following document: - 'Modern Problem Statement, Use Cases, and Framework' (draft-ietf-modern-problem-framework-04.txt) as Informational RFC This document is the product of the Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-modern-problem-framework/ Technical Summary 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. Working Group Summary There was some controversy when the MODERN working group was formed about the scope of work for the group. Discussions around these concerns resulted in clarifications of the architecture and requirements reflected in this document. In the end there was strong working group consensus on the contents of this document. Document Quality This document is an architecture and requirements document. As such, it does not define a protocol or anything that can be directly implemented. Personnel Steve Donovan is the Document Shepherd. Adam Roach is the Responsible Area Director. IESG Note This document is an informational use case and architecture document. The working group wishes to publish it as an RFC because it contains important terminology and concepts that will be referenced from the solutions RFCs. From nobody Thu Mar 29 10:44:31 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 A0CB612E038 for ; Thu, 29 Mar 2018 10:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_NEUTRAL=0.779] autolearn=no 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 ITwAgaW-y-Pv for ; Thu, 29 Mar 2018 10:44:25 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) (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 8ECC512E055 for ; Thu, 29 Mar 2018 10:44:25 -0700 (PDT) Received: from [97.99.50.102] (port=65124 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1f1bay-002JFt-1p for modern@ietf.org; Thu, 29 Mar 2018 10:44:22 -0700 To: "modern@ietf.org" From: Steve Donovan Message-ID: <93f728e4-2544-2b77-d143-3f53825d4506@usdonovans.com> Date: Thu, 29 Mar 2018 12:44:15 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [Modern] Call for adoption of draft-peterson-modern-teri as a working group document 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, 29 Mar 2018 17:44:27 -0000 All, During the MODERN session at IETF 101 in London there was consensus reached in the room to adopt draft-peterson-modern-teri as a working group draft. The next step is to confirm that consensus here on the MODERN mailing list. We'll leave the question open for two weeks. Regards, Steve