Re: [Ecrit] AD review: draft-ietf-ecrit-additional-data-29

[Randall Gellens <[e-mail]>]

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 <[e-mail]> 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
>>>  <[e-mail]> 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.