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

[Randall Gellens <[e-mail]>]

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:

>  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:[e-mail]] On Behalf Of Alissa Cooper
>>>>    Sent: 30 April 2015 23:57
>>   ...snip...
>>>    _______________________________________________
>>>    Ecrit mailing list
>>>    [e-mail]
>>>    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.
>
>  _______________________________________________
>  Ecrit mailing list
>  [e-mail]
>  https://www.ietf.org/mailman/listinfo/ecrit



-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
A day for firm decisions!!!!!  Or is it?