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

[Randall Gellens <[e-mail]>]

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


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

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

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

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

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

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
>>  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
>>
>  _______________________________________________
>  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: ---------------
Any given program costs more and takes longer.