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

From: Randall Gellens <[email-masked]>
Date: Wed, 1 Jul 2015 06:41:42 -0700

Hi Alissa and Keith,

Version -30 is now published and contains all 
changes addressing all comments from both of you.

Thanks again for your reviews, I and my fellow authors appreciate it.

At 6:55 PM -0700 6/28/15, Randall Gellens wrote:

>  Hi Keith,
>
>  Thanks for your comments.  I've addressed them 
> in-line below, and changes are in -30.
>
>  At 11:45 AM +0000 5/1/15, Keith (Keith) DRAGE wrote:
>
>>   This part of Alissa's review caught my eye 
>> because I think the original intent is wrong, 
>> and therefore so is the rewrite:
>  ...snip...
>>      header of a SIP message. It has no meaning 
>> outside the context of an emergency call."
>
>  The intent is not interoperability per se but 
> rather protection.  The original text was 
> trying to say "It's a really bad idea to send 
> this data in anything other than an emergency 
> call."  It's also true that a purpose value 
> starting with 'EmergencyCallData.' is only 
> defined for use within an emergency call; use 
> outside this context is a Bad Idea as well as 
> undefined.  Although there is an exception, 
> which is private emergency call, e.g., the call 
> leg between a vehicle and a service provider 
> call center, but that's a private use between 
> endpoints by prior agreement.  Another 
> exception to Keith's proposed text is a test 
> call.
>
>  I added a modified form of Keith's text:
>
>      A Call-info header with a purpose value starting with
>      'EmergencyCallData' only has meaning in the context of an
>      emergency call (including test emergency calls); use in other
>      contexts is undefined and is likely to unnecessarily expose
>      confidential data
>
>>   As a result of opening the document again I 
>> also noted the following that would be worthy 
>> of comment.
>>
>>   Section 4.2.3:
>>
>>   OLD TEXT
>  ...snip...
>>   What is the real requirement here, does it 
>> apply to something within the scope of this 
>> document, and can it be tested.
>
>  The intent of the text is to specify that 
> dereferencing results in a standardized data 
> structure, which is necessary for 
> interoperability; it wasn't intended to require 
> that the reference remain valid for some period 
> of time, although since you bring it up, it 
> would be reasonable to require that it remain 
> valid for a specific period of time after 
> termination of the call.
>
>>   Section 5
>>   -----------
>>
>>   OLD TEXT
>>
>>   Every block must be
>>      one of the types in the registry.
>>
>>   As specified this can be confused ...
>>  ...snip...
>>  ... in the document. I assume "service type". I would suggest.
>>
>>   "All service types used in blocks are expected to be registered"
>
>  It means the type of data block, that is, which 
> data block, as registered in the Emergency Call 
> Data Types Registry.  The document defines a 
> set of data blocks and establishes a registry 
> so that the set can be expanded.  The text is 
> trying to say that any of the set of data 
> blocks may be sent, and only registered blocks 
> can be sent, for interoperability (the receiver 
> must know how to interpret the blocks).
>
>>   But it is dubious whether we need any 
>> sentence at all rather than the implicit one 
>> that says "If a registry is provided for an 
>> element then all values are expected to be 
>> registered".
>
>  It's the corollary of the previous sentence; 
> that is: "One or more blocks [of the registered 
> set of blocks] may be sent.  Every block must 
> be [a member of the set]"
>
>  I've reworded the text to be:
>
>     One or more blocks of data registered in the Emergency Call
>     Additional Data registry, as defined in Section 10.1.9, can be
>     included or referenced in the SIP signaling (using the Call-Info
>     header field) or in the <provided-by> element of a PIDF-LO.  For
>     interoperability, only blocks in the registry are permitted to be
>     sent using the mechanisms specified in this document.
>
>>   Section 9
>>   ----------
>>
>>   OLD TEXT
>>
>>   Local regulations
>>      may govern what data must be provided in emergency calls, but in
>>      general, the emergency call system is aided by the information
>>      described in this document.
>>
>>   /must be/is/
>
>  Agreed.
>
>>   Section 10.1.9
>>   --------------
>>
>>   OLD TEXT
>>
>>   This document creates a new sub-registry called 'Device/Service Data
>>  ...snip...
>>  ... details about what the implicit expert 
>> review associated with this policy requires.
>>
>>   Similar comments apply elsewhere e.g. 10.1.10
>
>  Agreed, done.
>
>>   Like Alissa I would prefer that all the 
>> material that IANA has to deal with is within 
>> the IANA considerations sections, and not 
>> referenced back to other parts of the document 
>> (even if that means duplication of text).
>
>  Alissa asked that the initial values all be in 
> one place, either all in the block definitions, 
> or all in the IANA section.  After discussing 
> with my coauthors, we decided the best approach 
> is to have all tables in the block definitions.
>
>>   Section 10.2
>>   ------------
>>
>>   TEXT
>>
>>   Note that 'EmergencyCallData'
>>      is a compound value; when used as a value of the 'purpose' parameter
>  ...snip...
>>      registry Section 10.1.10.
>>
>>   This text would appear to be nothing to do 
>> with the registry or the values placed in the 
>> registry.
>
>  The text is adding a new value to the 'purpose' 
> parameter value registry.  The fact that the 
> new value is compound is significant.
>
>>   Other comment
>>   -------------
>>
>>   RFC 3261 contains the statement in section 16.6.
>>
>>   The proxy MUST NOT add to, modify,
>>  ...snip...
>>  ... and not add to the body. In order to add 
>> to the body it must be a B2BUA. This should be 
>> identified somewhere in the document.
>
>  I've added text to this effect in section 5.1
>
>>>   -----Original Message-----
>>>   From: Ecrit [mailto:[email-masked]] On Behalf Of Alissa Cooper
>>>   Sent: 30 April 2015 23:57
>  ...snip...
>>   _______________________________________________
>>   Ecrit mailing list
>>   [email-masked]
>>   https://www.ietf.org/mailman/listinfo/ecrit
>

At 6:53 PM -0700 6/28/15, Randall Gellens wrote:

>  At 3:56 PM -0700 4/30/15, Alissa Cooper wrote:
>
>>   I have reviewed 
>> draft-ietf-ecrit-additional-data-29 in 
>> preparation for IETF last call. There are a 
>> number of issues that need to be resolved 
>> before the IETF LC can be issued, which IÕve 
>> included below as substantive comments and 
>> questions. There is a list of nits at the end 
>> that also need to be fixed.
>
>  Thank you very much, I appreciate it.  I've 
> addressed them below and the -30 has the 
> changes.
>
>>   Substantive comments and questions:
>>
>>   General:
>>   I've asked the shepherd to validate all of 
>> the XML in the document and am waiting to hear 
>> back on that.
>
>  This is in progress; several small errors have 
> been identified and fixed so far.
>
>>   Section 1:
>>   I would suggest adding this text from Section 
>> 9 or something like it at the end of the 
>> introduction:
>  ...snip...
>>      of an emergency call is a trade-off to protect the greater interest
>>      of the customer in an emergency."
>
>  I agree, done.
>
>>   Section 4.1:
>>   I am a little confused about how this section 
>> applies when the data is being provided by the 
>> device. First, this ...
>>  ...snip...
>>   I think this would be clearer if the first 
>> sentence said "any service provider in the 
>> path of the call, the access network provider, 
>> or the device."
>
>  I agree, done.
>
>>   Then later in the section Data Provider ID, 
>> Data Provider ID Series, and Type of Data 
>> Provider are defined. None of these seem ...
>>  ...snip...
>>  ... Section 6 that only Type of Data Provider 
>> is included, and is listed as ÒOther,Ó which 
>> seems less specific than it ideally could be.
>
>  In reviewing the various elements in this 
> block, I saw that in some cases there was text 
> explaining how the element is set by the device 
> but not in all cases.  I have added text where 
> it was missing and clarified some of the other 
> text. In the Type of Data Provider registry, I 
> expanded the description of the "client" value 
> to be "Originating client/device" to make it 
> clear that this is the appropriate value when 
> set by the device.
>
>>   Section 4.1.2:
>>   Is there an EENA equivalent of the NENA 
>> company ID? If so, it should be mentioned here.
>
>  I am not aware that EENA has yet established 
> such a registry, but the 'EENA' value is 
> present in anticipation.
>
>>   Is it the case that where a 
>> jurisdiction-specific ID exists, it is 
>> preferred over an FQDN? If so, that should be 
>> stated explicitly.
>
>  Thanks, I have clarified the text to try to make this very clear.
>
>>   Section 4.1.5:
>>   "If the call is from a device, this SHOULD be the contact
>>         information of the owner of the device."
>>
>>   What are the exception cases for this SHOULD? 
>> What should this element be if it is not the 
>> owner's contact info?
>
>  Normally, the device owner and user are the 
> same, but when they are different, the contact 
> info SHOULD be for the user, but MAY be for the 
> owner. I have clarified the text to make this 
> more clear.
>
>>   Section 4.1.6:
>>   By saying the other language tags are 
>> independent of this language element, does 
>> that mean they should be ignored? If so, that 
>> should be stated explicitly.
>
>  It's not that anything is being ignored, it's 
> that these are entirely separate things.  The 
> field in 4.1.6 is for information to a human: 
> it informs the PSAP person who needs to contact 
> the data provider as to the language(s) used by 
> the data provider.  If the PSAP needs to 
> contact the data provider, it can be helpful to 
> know in advance the language(s).  If the PSAP 
> uses a communication protocol to reach the data 
> provider, that protocol may have language 
> facilities of its own, and if so, those are 
> independent of this field.  I've clarified the 
> text.
>
>>   Section 4.1.9:
>>   "This element is required if the Data Provider
>>         type is set to "Subcontractor"."
>>
>>   Subcontractor is not listed as a data 
>> provider type in section 4.1.4, so this 
>> doesn't quite make sense.
>
>  This is supposed to say "This data is required 
> if the entity providing the data is a 
> subcontractor."  Thanks.
>
>>   Section 4.2.1:
>>   Shouldn't "use" be listed as conditional?
>
>  Yes, I agree it is more clear that way.
>
>>   Section 4.2.3:
>>   s/MUST NOT/ought not to/
>
>  Yes, I agree.
>
>>   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.  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).
>
>>   Section 4.4.1:
>>   Are there any jurisdiction-specific rules you 
>> can point to that would indicate that having a 
>> single boolean "privacy ...
>>  ...snip...
>>  ... least some places have well-specified 
>> rules for what to do when they receive this 
>> value), this indicator seems pretty hand-wavy.
>
>  I know it's messy to have a single 'privacy' 
> flag whose interpretation is left to each 
> jurisdiction, but this exactly matches the 
> semantics of the equivalent privacy indicator 
> provided in some legacy emergency call systems. 
> I've added some text to this effect.
>
>>   Section 4.4.2:
>>   Are there any xCard fields you would 
>> recommend not sending for lack of relevance 
>> (e.g., anniversary)?
>
>  That's a good question.  The answer is that 
> name, address, and phone number(s) are the 
> minimum, but anything else might potentially be 
> useful in some circumstances.  I've added text 
> to this effect.
>
>>   Depending on what the answer is to my 
>> question in 4.1.6 about interaction between 
>> Data Provider Language(s) and language tags, 
>> there might need to be text in this section as 
>> well about expected behavior when both are 
>> present and when the data provider is the 
>> device.
>
>  Since these are entirely separate and don't 
> interact, and I've added clarifying text in 
> 4.1.6, I don't think anything here is needed, 
> although I'm open to adding additional 
> clarifying text here if you think it helpful.
>
>>   Section 5.1:
>>   The last paragraph here makes it sound as 
>> though additional data is required to be sent 
>> on every emergency call ...
>>  ...snip...
>>  ... in the document, preferably in the 
>> introduction. If not, the normative language 
>> in the last paragraph here needs to be fixed.
>
>  The intent is that every emergency call carry 
> the information described here using the 
> mechanisms described here.  I've added text to 
> this effect in both the Abstract and the 
> Introduction. Thanks for pointing out that it 
> wasn't clear that this is the intent.
>
>>   Section 6:
>>   The owner/subscriber of this laptop is Hannes 
>> Tschofenig. His contact tel URI is in North 
>> America but his work and ...
>>  ...snip...
>>  ... require more narrative explanation in the 
>> text. Alternatively, a simpler or more 
>> plausible example might help readers out more.
>
>  Wow, I'm quite impressed that you went to this 
> much work!  I never expected anyone to pull out 
> each of these parts from an example, put them 
> together, and see if they were internally 
> consistent.  The least I can do is try to 
> improve it, so I added 'home' entries to the 
> xCard for <addr>, <tel>, and <geo> for a 
> location within the U.S. to the device-provided 
> info, moved the VoIP provider from London to 
> Iowa (with appropriate address and time zone 
> information), switched the PIDF-LO from the 
> access network to be a U.S. address, and 
> switched the access network provider to be an 
> Access Network type rather than "other".
>
>>   Section 8:
>>   "Mechanisms that
>>      protect against eavesdropping (such as Transport Layer Security
>  ...snip...
>>   s/Service providers SHOULD choose the 
>> latter/Service providers ought to choose the 
>> latter/
>>   (otherwise this reads like a normative requirement on IMS functionality)
>
>  Thanks very much for these comments, I've made 
> corrections to section 8 for all of them.
>
>>   Section 10.1.1:
>>   "Private entities issuing and using internally-generated IDs are
>>      encouraged to register and use a unique identifier."
>>
>>   What is meant by "use a unique identifier"?
>
>  The idea is that some organizations, such as 
> NENA, issue IDs that are unique among all IDs 
> they issue, so a combination of the NENA ID and 
> the fact that it is from NENA is globally 
> unique. Other entities may not have an ID 
> issued by an organization such as NENA, so they 
> are permitted to use their domain name.  I've 
> reworded the text to try and make this more 
> clear.
>
>>   Section 10.1.8:
>>   It might be useful to give the experts some 
>> additional criteria around weighing privacy 
>> vs. utility trade-offs ...
>>  ...snip...
>>  ... to authenticate a device as a device ID 
>> and few or no PSAPs can actually make use of 
>> it, that may argue against registering it.
>
>  I think the text "The expert should ascertain 
> that ... the information [is] useful to PSAPs 
> and responders to uniquely identify a device" 
> would disallow a biometric fingerprint (since 
> it isn't useful for a PSAP, but I'm happy to 
> add more clarifying text here.
>
>>   Section 12.2:
>>   I think RFC 3966 should be a normative reference.
>
>  OK.
>
>>   Nits:
>>
>>   General:
>>   Why are some of the registry tables in the 
>> main sections of the document and others are 
>> in the IANA Considerations section? Seems like 
>> they should all be one or the other.
>
>  I moved all the tables to be in the block definitions.
>
>>   Section 2:
>>   Citations for vCard and xCard should be added to the last paragraph.
>
>  Agreed, done.
>
>>   Section 4.1.7:
>>   This sentence seems redundant: "For encoding of the xCard this
>>         specification uses the XML-based encoding specified in [RFC6351],
>>         referred to in this document as "xCard"."
>
>  Yes, it should say "For encoding of the vCard."
>
>>    ÊÊÊÊ
>>   Section 4.2.1:
>>   s/therefore this is/this is/
>
>  Done
>
>>   s/Figure 22/Section 10.1.2/
>
>  Done
>
>>   Section 4.2.2:
>>   s/Figure 3/Section 10.1.3/
>
>  Done
>
>>   Section 4.2.3:
>>   s/Figure 23/Section 10.1.4/
>
>  Done
>
>>   Section 4.3.6:
>>   A reference to the IEEE 1512 spec should be included.
>
>  Done
>
>>   Section 4.3.7:
>>   s/which allow/that allow/
>
>  Done
>
>>   "Some standards being developed by other 
>> organizations" -- would be good to provide 
>> citations.
>
>  I reworded the text to be simpler and avoid the reference.
>
>>   Section 4.4.2:
>>   Given that 4.4 says the location provided 
>> here is the contact address and not 
>> necessarily the location of the caller, it 
>> seems like this section needs to explain a 
>> little more why a call taker would use the 
>> location provided here.
>
>  I agree, and added some additional text.
>
>>   Section 5.1:
>>   OLD
>>   A Call-info header with a purpose value starting with
>>      'EmergencyCallData' MUST only be sent on an emergency call
>>   NEW
>>   A Call-info header with a purpose value starting with
>>      'EmergencyCallData' MUST NOT be sent 
>> unless the call is an emergency call
>
>  Edited per Keith's reply to your comment.
>
>>    Ê
>>   Section 9:
>>   s/The functionality defined in this document, 
>> however/The functionality defined in this 
>> document/
>
>  Done.
>
>>   Section 10.1.2:
>>   s/A s[RFC4119]hort/A short/
>
>  Previously fixed.
>
>>   Section 10.1.5:
>>   Seems like this section and Figure 1 should 
>> both use "Token" rather than "Tokenproviderid."
>
>  Yes, done.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
No one expects Braniff to go broke. No major U.S. carrier ever has.
        --The Wall Street Journal, 30 July 1980.

---

From: Randall Gellens <[email-masked]>
Date: Wed, 1 Jul 2015 06:55:38 -0700

Also, Hannes has verified the XML examples 
against the schemas.  There is a new Appendix B 
with some notes on what is required (e.g., due to 
line breaks/whitespace introduced by I-D/RFC 
format),

At 6:41 AM -0700 7/1/15, Randall Gellens wrote:

>>   Thanks for your comments.  I've addressed 
>> them in-line below, and changes are in -30.
>>
>>>       header of a SIP message. It has no 
>>> meaning outside the context of an emergency 
>>> call."
>>
>> which is private emergency call, e.g., the 
>> call leg between a vehicle and a service 
>> provider call center, but that's a private use 
>> between endpoints by prior agreement.  Another 
>> interoperability; it wasn't intended to 
>> require that the reference remain valid for 
>> some period of time, although since you bring 
>> it up, it would be reasonable to require that 
>> it remain valid for a specific period of time 
>> after termination of the call.
>>
>>>    Section 5
>>>    -----------
>>>
>>>    OLD TEXT
>>>
>>>    Every block must be
>>   It means the type of data block, that is, 
>> which data block, as registered in the 
>> Emergency Call Data Types Registry.  The 
>> document defines a set of data blocks and 
>> establishes a registry so that the set can be 
>> expanded.  The text is trying to say that any 
>> of the set of data blocks may be sent, and 
>> only registered blocks can be sent, for 
>> interoperability (the receiver must know how 
>> to interpret the blocks).
>>
>> that is: "One or more blocks [of the 
>> registered set of blocks] may be sent.  Every 
>> block must be [a member of the set]"
>>
>>> referenced back to other parts of the 
>>> document (even if that means duplication of 
>>> text).
>>
>>   Alissa asked that the initial values all be 
>> in one place, either all in the block 
>> definitions, or all in the IANA section. 
>> After discussing with my coauthors, we decided 
>> the best approach is to have all tables in the 
>> block definitions.
>>
>>>    Section 10.2
>>>    ------------
>>>
>>>    TEXT
>>>
>>   The text is adding a new value to the 
>> 'purpose' parameter value registry.  The fact 
>> that the new value is compound is significant.
>>
>>>    Other comment
>>>    -------------
>>>
>>> to the body it must be a B2BUA. This should 
>>> be identified somewhere in the document.
>>
>>> the XML in the document and am waiting to 
>>> hear back on that.
>>
>>   This is in progress; several small errors 
>> have been identified and fixed so far.
>>
>>>    Section 1:
>>>    I would suggest adding this text from 
>>> Section 9 or something like it at the end of 
>>> the introduction:
>>   ...snip...
>>>    I am a little confused about how this 
>>> section applies when the data is being 
>>> provided by the device. First, this ...
>>>   ...snip...
>>> path of the call, the access network 
>>> provider, or the device."
>>
>>   I agree, done.
>>
>>>   ... Section 6 that only Type of Data 
>>> Provider is included, and is listed as 
>>> ÒOther,Ó which seems less specific than it 
>>> ideally could be.
>>
>> explaining how the element is set by the 
>> device but not in all cases.  I have added 
>> text where it was missing and clarified some 
>> of the other text. In the Type of Data 
>> Provider registry, I expanded the description 
>> of the "client" value to be "Originating 
>> client/device" to make it clear that this is 
>> the appropriate value when set by the device.
>>
>>>    Section 4.1.2:
>>>    What are the exception cases for this 
>>> SHOULD? What should this element be if it is 
>>> not the owner's contact info?
>>
>> info SHOULD be for the user, but MAY be for 
>> the owner. I have clarified the text to make 
>> this more clear.
>>
>>>    Section 4.1.6:
>> it informs the PSAP person who needs to 
>> contact the data provider as to the 
>> language(s) used by the data provider.  If the 
>> PSAP needs to contact the data provider, it 
>> can be helpful to know in advance the 
>> language(s).  If the PSAP uses a communication 
>> protocol to reach the data provider, that 
>> protocol may have language facilities of its 
>> own, and if so, those are independent of this 
>> field.  I've clarified the text.
>>
>>>    Section 4.1.9:
>>   This is supposed to say "This data is 
>> required if the entity providing the data is a 
>> subcontractor."  Thanks.
>>
>>>    Section 4.2.1:
>>   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.  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).
>>
>>>    Section 4.4.1:
>>>    Are there any jurisdiction-specific rules 
>>> you can point to that would indicate that 
>>> having a single boolean "privacy ...
>>>   ...snip...
>> provided in some legacy emergency call 
>> systems. I've added some text to this effect.
>>
>>>    Section 4.4.2:
>> minimum, but anything else might potentially 
>> be useful in some circumstances.  I've added 
>> text to this effect.
>>
>>> there might need to be text in this section 
>>> as well about expected behavior when both are 
>>>    The owner/subscriber of this laptop is 
>>> Hannes Tschofenig. His contact tel URI is in 
>>> North America but his work and ...
>>>   ...snip...
>>>   ... require more narrative explanation in 
>>> the text. Alternatively, a simpler or more 
>>   Wow, I'm quite impressed that you went to 
>> this much work!  I never expected anyone to 
>> pull out each of these parts from an example, 
>> put them together, and see if they were 
>> internally consistent.  The least I can do is 
>> try to improve it, so I added 'home' entries 
>> to the xCard for <addr>, <tel>, and <geo> for 
>> a location within the U.S. to the 
>> device-provided info, moved the VoIP provider 
>> from London to Iowa (with appropriate address 
>> and time zone information), switched the 
>> PIDF-LO from the access network to be a U.S. 
>> address, and switched the access network 
>> provider to be an Access Network type rather 
>> than "other".
>>
>>>    Section 8:
>>>    "Mechanisms that
>>   Thanks very much for these comments, I've 
>> made corrections to section 8 for all of them.
>>
>>>    Section 10.1.1:
>> they issue, so a combination of the NENA ID 
>> and the fact that it is from NENA is globally 
>> issued by an organization such as NENA, so 
>> they are permitted to use their domain name. 
>> I've reworded the text to try and make this 
>> more clear.
>>
>>>    Section 10.1.8:
>>> in the IANA Considerations section? Seems 
>>> like they should all be one or the other.
>>
>>>    s/The functionality defined in this 
>>> document, however/The functionality defined 
>>> in this document/
>>
>>   Done.
>>
>>>    Section 10.1.2:

-------------- Randomly selected tag: ---------------
A day for firm decisions!!!!!  Or is it?

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 9 Jul 2015 15:19:35 -0700

Hi Randy,

Thanks for addressing my comments. I have one follow-up below.

On Jun 28, 2015, at 6:53 PM, Randall Gellens <[email-masked]> 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.
> 
> 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?

> 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.

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.

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 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.

Thanks,
Alissa

---

From: Randall Gellens <[email-masked]>
Date: Thu, 9 Jul 2015 18:47:37 -0700

>  Thanks for addressing my comments. I have one follow-up below.

Hi Alissa,

Thanks very much.  Please see in-line.

>  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.

>  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.

>
>  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.

-------------- Randomly selected tag: ---------------
Whenever you find that you are on the side of the majority,
it is time to reform.                         --Mark Twain

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 16 Jul 2015 17:39:56 -0700

Hi Randy,

Thanks for your response.

> older kids who think it's funny.

Ok

> could happen with specialized devices.

Some text to justify the different identifiers would be good to add to the draft.

> 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.

Thanks,
Alissa

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 17 Jul 2015 15:59:34 +0000

> 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…
There are jurisdictions that, for example, would consider the telephone number to be private, and that is not in the owner/subscriber block.  But all of the data in that block is affected by the privacy indicator in all the jurisdictions I’m aware of.  So, I do think it’s in the right place.

Randy’s point was that what it means changes from one jurisdiction to another, so what fields it affects could vary, and which blocks they are a part of will vary.  I don’t think we want to make the mechanism more complex. 

Brian

---

From: Randall Gellens <[email-masked]>
Date: Sun, 19 Jul 2015 02:49:54 -0700

Hi Alissa,

>  Some text to justify the different identifiers would be good to add 

I'm not really sure what text would be helpful.

>  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.

-------------- 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.

---

From: Alissa Cooper <[email-masked]>
Date: Sun, 19 Jul 2015 12:20:24 +0200

> Randy’s point was that what it means changes from one jurisdiction to another, so what fields it affects could vary, and which blocks they are a part of will vary.  I don’t think we want to make th…

Ok. If you could add a sentence to the description to make it clear that the application of the indicator may extend to any of the additional data shared, I think that would help.

Thanks,
Alissa

---

From: Randall Gellens <[email-masked]>
Date: Sun, 19 Jul 2015 07:53:38 -0700

At 12:20 PM +0200 7/19/15, Alissa Cooper wrote:

>>> data, but if it could be interpreted more broadly then I'm not 
>>> sure it makes sense to put it in that block.
>>>
>>  There are jurisdictions that, for example, would consider the 
>> telephone number to be private, and that is not in the 
>> owner/subscriber block.  But all of the data in that block is 
>> affected by the privacy indicator in all the jurisdictions I'm 
>> aware of.  So, I do think it's in the right place.
>>
>>  Randy's point was that what it means changes from one jurisdiction 
>> to another, so what fields it affects could vary, and which blocks 
>> they are a part of will vary.  I don't think we want to make the 
>> mechanism more complex.
>
>  Ok. If you could add a sentence to the description to make it clear 
> that the application of the indicator may extend to any of the 
> additional data shared, I think that would help.

Happy to.  I added:

	Because the interpretation of this indicator varies based on 
local regulations, this document cannot describe the exact semantics 
nor indicate which fields are affected (the application of this 
indicator might affect the display of data contained in any of the 
blocks).

-------------- Randomly selected tag: ---------------
It is much easier to suggest solutions
when you know nothing about the problem.