Re: [Ecrit] AD review: draft-ietf-ecrit-additional-data-29
Randall Gellens <rg+ietf@qti.qualcomm.com> Sun, 19 July 2015 09:50 UTC
Return-Path: <rg+ietf@qti.qualcomm.com>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B82E1A9040 for <ecrit@ietfa.amsl.com>; Sun, 19 Jul 2015 02:50:28 -0700 (PDT)
X-Quarantine-ID: <yIc2tR-I2LeJ>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIc2tR-I2LeJ for <ecrit@ietfa.amsl.com>; Sun, 19 Jul 2015 02:50:26 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C881F1A8A78 for <ecrit@ietf.org>; Sun, 19 Jul 2015 02:50:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1437299426; x=1468835426; h=message-id:in-reply-to:references:date:to:from:subject: cc; bh=dQ0X1tK8aG330o7sa5hJFgkMKGOfpy3mTbQ2kTyCNd8=; b=YRxRSlxm2IOHwSpipL7DyLctknmvekTZJNZ/bBCsPNGBg7chqtfHnWTI sVqDy6Yjzstp891NuJlxWzcLu4zv7YFO3pQuiCIa/44NaD27E+vueMsf7 IvsiYdvvcqi5v5vZ/uLuQpxuEEaDMAo0V1HC4nE7+qyDDtmyKHte4e0Te M=;
X-IronPort-AV: E=McAfee;i="5700,7163,7866"; a="94148934"
Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jul 2015 02:50:26 -0700
X-IronPort-AV: E=Sophos;i="5.15,502,1432623600"; d="scan'208";a="482116455"
Received: from plus.qualcomm.com ([10.52.255.8]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jul 2015 02:50:24 -0700
Received: from Ironmsg04-L.qualcomm.com (ironmsg04-L.qualcomm.com [172.30.48.19]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t6J9oN7O030237; Sun, 19 Jul 2015 02:50:23 -0700
X-IronPort-AV: E=Sophos;i="5.15,502,1432623600"; d="scan'208";a="938163075"
X-ojodefuego: yes
Received: from unknown (HELO [130.129.14.251]) ([10.64.229.15]) by Ironmsg04-L.qualcomm.com with ESMTP; 19 Jul 2015 02:49:57 -0700
Mime-Version: 1.0
Message-Id: <p06240600d1d122b50de0@[130.129.14.251]>
In-Reply-To: <FFE14662-87AD-4970-8E3D-201203305B8D@cooperw.in>
References: <99E88B8D-C7E1-4C33-A5FC-45E105D28580@cooperw.in> <p06240600d194f63d737f@[99.111.97.136]> <AA8402BC-217E-4072-94A6-4C9B3BB2A08B@cooperw.in> <p0624060ad1c4cfdd4c23@[99.111.97.136]> <FFE14662-87AD-4970-8E3D-201203305B8D@cooperw.in>
X-Mailer: Eudora for Mac OS X
Date: Sun, 19 Jul 2015 02:49:54 -0700
To: Alissa Cooper <alissa@cooperw.in>, Brian Rosen <Brian.Rosen@neustar.biz>
From: Randall Gellens <rg+ietf@qti.qualcomm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: <http://mailarchive.ietf.org/arch/msg/ecrit/NgNsoDd3ALwwlG4ejlUWxV9lOlQ>
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] AD review: draft-ietf-ecrit-additional-data-29
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Jul 2015 09:50:28 -0000
Hi Alissa, At 5:39 PM -0700 7/16/15, Alissa Cooper wrote: > Hi Randy, > > Thanks for your response. > > On Jul 9, 2015, at 6:47 PM, Randall Gellens <rg+ietf@qti.qualcomm.com> wrote: > >> At 3:19 PM -0700 7/9/15, Alissa Cooper wrote: >> >>> Hi Randy, >>> >>> Thanks for addressing my comments. I have one follow-up below. >> >> Hi Alissa, >> >> Thanks very much. Please see in-line. >> >>> On Jun 28, 2015, at 6:53 PM, Randall Gellens >>> <rg+ietf@qti.qualcomm.com> wrote: >>> >>>>> >>>>> Section 4.3.4: >>>>> I'm curious about the kinds of "investigations" >>>>> that PSAPs do and how they have used unique >>>>> device IDs in those investigations -- could you >>>>> explain? At first blush this seems to require >>>>> over-sharing of sensitive data. >>>> >>>> The most common situation that I'm aware of is >>>> repeated false/accidental calls. If there is no >>>> callback number or it isn't usable, the PSAP may >>>> need to try and track down the device by >>>> contacting the service providers in the area. In >>>> the case of handsets without current service, >>>> they may be able to determine who last had >>>> service. >>> >>> How does the user make an emergency call without current service? >> >> It varies by region; for example, in the U.S. and some European >> countries, telephone companies (cellular and wirelines) are required >> to provide emergency access (911 or 112) even if the device or >> landline has no service. So, old cell phones that haven't had >> service in years can still be used to dial 911 (or 112), and >> landlines that have been turned off for non-payment can usually still >> dial 911. The situation with landlines is a little different from >> cell phones, so there can be a completely dead landline that is >> unable to dial 911. PSAPs do get lots false calls from old cell >> phones that parents have given to kids as toys, for example. Or >> older kids who think it's funny. > > Ok > >> >>>> There could be other situations where >>>> this might be useful (e.g., a disconnected call >>>> where the call taker believes there is a need for >>>> assistance but was not able to obtain a location >>>> or other information). >>> >>> It would be helpful if the above explanation could be included in >>> the draft. >> >> I have added this. >> >>> Given the explanation above, does it really make sense for the >>> device to be providing this information in addition to the service >>> provider? That is, the device may have many possible device IDs >>> that it could include, but it may not know which ones the service >>> provider collects and correlates to specific users, so it won't >>> necessarily know which ones to provide. Given that all of these IDs >>> can be uniquely identifying in different contexts, providing >>> multiple IDs that won't get used seems like not the best idea. And >>> if the user is abusing the emergency call system, he won't include >>> these anyway. >> >> An attacker won't include the information (or would include fake >> information), but a legitimate device that is used by someone playing >> pranks, or kids as a toy, or someone who does need help and is using >> a device without service and can't provide any other information, >> would include information, and in these cases, it's better if the >> device includes it, since it's not clear what the service provider >> knows or will provide. >> >>> Are we sure that all of the device types specified actually get >>> used in this way by PSAPs? E.g., I was curious about whether >>> service providers track device RFIDs. >> >> I'm not aware of this being common with consumer devices, but it >> could happen with specialized devices. > > Some text to justify the different identifiers would be good to add > to the draft. I'm not really sure what text would be helpful. > >> >>> >>> I also think, as much as I dislike the subscriber privacy indicator >>> specified in 4.4.1, it should cover this data element as well, > >> particularly since this element can be inserted by the service >>> provider without the user knowing. >> >> The thing about the subscriber privacy indicator is that it's up to >> local regulation what elements it covers and what it means. I don't >> think we can dictate that. > > Well, does it have to be in the owner/subscriber block? I thought > that implied that it was only relevant to the owner/subscriber > data, but if it could be interpreted more broadly then I'm not sure > it makes sense to put it in that block. Brian addressed this in his reply; there really isn't a better place and I don't see it being harmful to leave it where it is. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Twenty-five per cent of the passengers of almost any aircraft show white knuckles on take-off. --Colin Marshall, CEO British Airways.
- [Ecrit] AD review: draft-ietf-ecrit-additional-da… Alissa Cooper
- Re: [Ecrit] AD review: draft-ietf-ecrit-additiona… DRAGE, Keith (Keith)
- Re: [Ecrit] AD review: draft-ietf-ecrit-additiona… Randall Gellens
- Re: [Ecrit] AD review: draft-ietf-ecrit-additiona… Randall Gellens
- Re: [Ecrit] AD review: draft-ietf-ecrit-additiona… Randall Gellens
- Re: [Ecrit] AD review: draft-ietf-ecrit-additiona… Randall Gellens
- Re: [Ecrit] AD review: draft-ietf-ecrit-additiona… Alissa Cooper
- Re: [Ecrit] AD review: draft-ietf-ecrit-additiona… Randall Gellens
- Re: [Ecrit] AD review: draft-ietf-ecrit-additiona… Alissa Cooper
- Re: [Ecrit] AD review: draft-ietf-ecrit-additiona… Rosen, Brian
- Re: [Ecrit] AD review: draft-ietf-ecrit-additiona… Randall Gellens
- Re: [Ecrit] AD review: draft-ietf-ecrit-additiona… Alissa Cooper
- Re: [Ecrit] AD review: draft-ietf-ecrit-additiona… Randall Gellens