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

["DRAGE, Keith (Keith)" <[e-mail]>]

This part of Alissa's review caught my eye because I think the original intent is wrong, and therefore so is the rewrite:

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

Unless this document updates RFC 3261, which it does not, it cannot preclude any string being sent in the purpose value.

This is nothing in the original text that is to do with interoperability, after all the recipient knows from other information that this is an emergency call, or not an emergency call. There is therefore no need to protect for wrong usage outside an emergency call.

So I believe that there is no need for any normative language here and rather what is meant is:

NEW TEXT

A Call-info header with a purpose value starting with
   'EmergencyCallData' only has meaning in the context of an emergency call, which can
   be ascertained by the presence of an emergency service urn in a Route
   header of a SIP message. It has no meaning outside the context of an emergency call."

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
----------
The URI, when dereferenced, MUST
      yield a data structure defined by the Device/service specific
      additional data type value.  

The normative requirement here is nothing to do with the dereferencing. It appears this is a requirement to keep the link between the URI and the data for a period of time; the period of time is not specified, but from the subsequent text would appear to be for the duration a responder might be involved in the emergency call.

What is the real requirement here, does it apply to something within the scope of this document, and can it be tested.

Section 5
-----------

OLD TEXT

Every block must be
   one of the types in the registry.

As specified this can be confused with a normative requirement. The registry is transient data and therefore cannot be tested against. It is also unclear what is meant by "type" as multiple types exist in the document. I assume "service type". I would suggest.

"All service types used in blocks are expected to be registered"

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

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/

Section 10.1.9
--------------

OLD TEXT

This document creates a new sub-registry called 'Device/Service Data
   Type Registry'.  As defined in [RFC5226], this registry operates
   under "Expert Review" and "Specification Required" rules.

Expert review and Specification required are two distinct categories of IANA policy. As written it might be assumed that either can be used. It is sufficient to say "Specification required" and then go into details about what the implicit expert review associated with this policy requires.

Similar comments apply elsewhere e.g. 10.1.10

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

Section 10.2
------------

TEXT

Note that 'EmergencyCallData'
   is a compound value; when used as a value of the 'purpose' parameter
   of the Call-Info header, 'EmergencyCallData' is immediately followed
   by a dot ('.') and a value from the 'Emergency Call Data Types'
   registry Section 10.1.10.

This text would appear to be nothing to do with the registry or the values placed in the registry.

Other comment
-------------

RFC 3261 contains the statement in section 16.6.

The proxy MUST NOT add to, modify,
         or remove the message body.

As this document does not update RFC 3261, I assume any intermediate SIP entity acting as a proxy can only alter the Call-Info header 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.
 
Regards

Keith


> -----Original Message-----
> From: Ecrit [mailto:[e-mail]] On Behalf Of Alissa Cooper
> Sent: 30 April 2015 23:57
> To: [e-mail]
> Subject: [Ecrit] AD review: draft-ietf-ecrit-additional-data-29
> 
> 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."
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
>