Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15

Hi Ivo,

At 12:48 AM +0000 10/17/16, Ivo Sedlacek wrote:

>  I identified a few issues:
>
>  ISSUE 1:
>
>  section 3 - given that the section 3 contains a lot of information 
> on legacy eCall in 3GPP, on ETSI requirements on NG-eCall, and CEN 
> documents, I wonder why the section 3 does not refer to 3GPP TS 
> 24.229 (particularly subclause 4.7.6) which gives details of 
> requirements on PSAP for usage of eCall in mobile environment.

Reference to TS24.229 added in section 4.  Section 3 has higher-level 
information and background, with references to SDOs rather than 
documents.  Section 4 has references to documents, which is where the 
reference to TS24.229 was added.

>
>  ISSUE 2:
>
>  section 3 - level of technical detail of the last paragraph of 
> section 3 does not fit with level of technical detail of the 
> remaining text of section 3.

Intermediate paragraphs were added in version 17.

>
>  ISSUE 3:
>
>  section 4 - add a reference to stage-3 requirements on eCall in 
> 3GPP TS 24.229.

Reference added.

>
>  ISSUE 4:
>
>  section 4, "   This document registers the 'application/
>     emergencyCallData.eCall.MSD+per' MIME Content-Type to enable the MSD
>     to be carried in SIP."
>
>  There is no MIME Content-Type registry. "MIME Content-Type" -> "MIME type"
>
>  Same in other places of the document.

Corrected "content type" to "media type".

>  ISSUE 6:
>
>  section 6 - "An MSD or a metadata/control block is always enclosed 
> in a multipart
>     body part (even if it would otherwise be the only body part in the
>     SIP message)." - which multipart MIME type is meant? 
> multipart/mixed or multipart/alternative or ....

We do not need to specify that in this text.

>
>  ISSUE 7
>
>  section 6 - "The IVS then attaches an updated MSD to a SIP
>     INFO request and sends it within the dialog." - what is meant by 
> "attaching MSD to SIP INFO request"?

I think that's made abundantly clear in the multiple earlier 
instances in the same section that say "as a MIME body part".

>
>  ISSUE 8
>
>  section 9 - "   If the IVS receives a SIP response without the 
> metadata/control
>     block, it indicates that the SIP dialog is not an NG-eCall (e.g.,
>     some part of the call is being handled as a legacy call)." - 
> needs to talk about final responses only, as earlier text states "A
>     metadata/control object is not attached to provisional (e.g., 180)
>     responses."

Agreed, fixed.

>
>  ISSUE 9
>
>  section 9 - what is "SIP status message"?

I do not see "SIP status message" anywhere in the document.

>
>  ISSUE 10
>
>  "
>  For
>     example, if a PSAP is unable to accept an eCall (e.g., due to
>     overload or too many calls from the same location), it can reject the
>     INVITE.  Since a metadata/control object is also included in the SIP
>     response that rejects the call, the IVS knows if the PSAP received
>     the MSD, and can inform the vehicle occupants that the PSAP
>     successfully received the vehicle location and information but can't
>     talk to the occupants at that time." - this prevents persons in 
> the car from getting emergency service of the PSAP using other 
> means (e.g. using circuit switched network). Possibility for DOS 
> attack.

If the PSAP is overloaded (e.g., there is a very large multi-vehicle 
incident, or another large-scale emergency incident), then there are 
likely to be multiple simultaneous eCall attempts.  The document does 
not in any way dictate or mandate PSAP response.  PSAPs are free to 
respond as they choose.  E.g., a PSAP can accept eCalls and add them 
to a queue, a PSAP can reject an eCall and include an ack with 
"received=false", a PSAP can reject an eCall and include an ack with 
"received=true".  Doing the latter indicates that the PSAP has 
received the MSD and hence is aware of the incident.

>
>  ISSUE 11
>
>  "The body for an emergencyCallData.eCall.MSD info package is a 
> multipart body." - which multipart MIME type is meant? 
> multipart/mixed or multipart/alternative or ....

We do not need to get into that level of detail in this text.

>
>  ISSUE 12
>
>  "Zero or one application/
>     emergencyCallData.eCall.MSD+per part (containing an MSD) and zero or
>     more application/emergencyCallData.control+xml (containing a
>     metadata/control object) parts are permitted." - this allows 
> INFO with no body part at all. If this is intentional, describe 
> when it is supposed to be used. If this is not intentional, state 
> that at least one of both is present.

I clarified this, thanks for catching it.

>
>  ISSUE 13
>
>  "Intermediate multipart
>     body parts MAY appear." - what does it mean? Where is 
> "Intermediate multipart body part" defined?

The text was deleted in version -16.

>
>  ISSUE 14
>
>  "while others can be
>     expected to carry an occasional request" - meaning of 
> "occasional" can be whatever, it depends on perspective of the user 
> - once per milisecond, once per second, once per minute, once per 
> hour or once per day?

Other text makes it clear that a request for an updated MSD is 
generally sent upon manual request of a PSAP call taker who suspects 
vehicle state may have changed.

>
>  ISSUE 15
>
>  Figure 8 expects location body by inclusion of Geolocation: 
> <cid:target123@example.com> but does not show it.