Re: [Modern] Benoit Claise's No Objection on draft-ietf-modern-problem-framework-03: (with COMMENT)

"Peterson, Jon" <jon.peterson@team.neustar> Thu, 01 March 2018 15:30 UTC

Return-Path: <prvs=059847ed44=jon.peterson@team.neustar>
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" <jon.peterson@team.neustar>
To: Benoit Claise <bclaise@cisco.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-modern-problem-framework@ietf.org" <draft-ietf-modern-problem-framework@ietf.org>, "modern-chairs@ietf.org" <modern-chairs@ietf.org>, "srdonovan@usdonovans.com" <srdonovan@usdonovans.com>, "modern@ietf.org" <modern@ietf.org>, "ldunbar@huawei.com" <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, 01 Mar 2018 15:30:16 +0000
Message-ID: <D6BD53C7.1F695F%jon.peterson@neustar.biz>
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: <https://mailarchive.ietf.org/arch/msg/modern/-6mLWD2AWPWBvut8_MFTaNgq0Aw>
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" <modern.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/modern>, <mailto:modern-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/modern/>
List-Post: <mailto:modern@ietf.org>
List-Help: <mailto:modern-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/modern>, <mailto:modern-request@ietf.org?subject=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" <bclaise@cisco.com> 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.
>
>