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

[Alissa Cooper <[e-mail]>]

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.

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.

Section 1:
I would suggest adding this text from Section 9 or something like it at the end of the introduction:

"Much of the information supplied by service providers and devices is
   private and confidential; service providers and devices generally go
   to lengths to protect this information; disclosing it in the context
   of an emergency call is a trade-off to protect the greater interest
   of the customer in an emergency."

Section 4.1:
I am a little confused about how this section applies when the data is being provided by the device. First, this text seems to consider the device to be a "service provider":

"This block is intended to be supplied by any service provider in the
   path of the call or the access network provider.  It includes
   identification and contact information.  This block SHOULD be
   supplied by every service provider in the call path, and by the
   access network provider.  Devices MAY use this block to provide
   identifying information."

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

Then later in the section Data Provider ID, Data Provider ID Series, and Type of Data Provider are defined. None of these seem to apply when the data is provided by the device, and yet they are all listed as required. What are these elements supposed to contain when the data is provided by the device? I see in the example in Section 6 that only Type of Data Provider is included, and is listed as “Other,” which seems less specific than it ideally could be.

Section 4.1.2:
Is there an EENA equivalent of the NENA company ID? If so, it should be mentioned here. 

Is it the case that where a jurisdiction-specific ID exists, it is preferred over an FQDN? If so, that should be stated explicitly.

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?

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.

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.

Section 4.2.1:
Shouldn't "use" be listed as conditional?

Section 4.2.3:
s/MUST NOT/ought not to/

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.

Section 4.4.1:
Are there any jurisdiction-specific rules you can point to that would indicate that having a single boolean "privacy" value will actually be interpretable and of use by any PSAP? I find it a little hard to believe that PSAPs will know what actions this value is supposed to apply to (e.g., display, logging, display and logging, etc.) and what data fields it is supposed to apply to. Without further definition (or some compelling evidence that PSAPs in at least some places have well-specified rules for what to do when they receive this value), this indicator seems pretty hand-wavy.

Section 4.4.2:
Are there any xCard fields you would recommend not sending for lack of relevance (e.g., anniversary)?

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.

Section 5.1:
The last paragraph here makes it sound as though additional data is required to be sent on every emergency call (i.e., every call with an emergency service URN in the route header). Is that the intention? If so, that needs to be made more clear and should be explained earlier in the document, preferably in the introduction. If not, the normative language in the last paragraph here needs to be fixed.

Section 6:
The owner/subscriber of this laptop is Hannes Tschofenig. His contact tel URI is in North America but his work and home are in Finland. He is using a VoIP provider that provides its NENA ProviderID, which I assume indicates that the service is being provided in North America? The VoIP provider contact person is located in the UK, however. And then when the access network provides the location, it is in Australia.

The last bit just seems wrong to me, for a plausible emergency call. The other bits seem to amount to a possible (but not likely?) example scenario but the details require more narrative explanation in the text. Alternatively, a simpler or more plausible example might help readers out more.

Section 8:
"Mechanisms that
   protect against eavesdropping (such as Transport Layer Security
   (TLS)) SHOULD be preferentially used whenever feasible."

This needs a sentence about the existing deployed base of clear text SIP to explain why this requirement is not a MUST. 

s/HTTPS is specified/HTTPS is REQUIRED/

"Data provided by devices by reference have similar credential
   validation issues as for service providers, and the solutions are the
   same."

Maybe the solutions are the same, but aren't the challenges of doing this for every device much more significant? That seems worth mention.

s/Service providers SHOULD choose the latter/Service providers ought to choose the latter/
(otherwise this reads like a normative requirement on IMS functionality)

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"?

Section 10.1.8:
It might be useful to give the experts some additional criteria around weighing privacy vs. utility trade-offs. E.g., if someone wants to register the biometric fingerprint used 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.

Section 12.2:
I think RFC 3966 should be a normative reference.


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.

Section 2:
Citations for vCard and xCard should be added to the last paragraph.

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"."
      
Section 4.2.1:
s/therefore this is/this is/

s/Figure 22/Section 10.1.2/

Section 4.2.2:
s/Figure 3/Section 10.1.3/

Section 4.2.3:
s/Figure 23/Section 10.1.4/

Section 4.3.6:
A reference to the IEEE 1512 spec should be included.

Section 4.3.7:
s/which allow/that allow/

"Some standards being developed by other organizations" -- would be good to provide citations.

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.

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
   
Section 9:
s/The functionality defined in this document, however/The functionality defined in this document/

Section 10.1.2:
s/A s[RFC4119]hort/A short/

Section 10.1.5:
Seems like this section and Figure 1 should both use "Token" rather than "Tokenproviderid."