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

[Ivo Sedlacek <[e-mail]>]

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.

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.

ISSUE 3:

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

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.

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

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

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

ISSUE 9

section 9 - what is "SIP status message"?

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.

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

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.

ISSUE 13

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

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?

ISSUE 15

Figure 8 expects location body by inclusion of Geolocation: <cid:[e-mail]> but does not show it.

ISSUE 16

>From and To in Figure 9 do not fit From and To in Figure 8.

ISSUE 17

>From in Figure 10 does not contain tag.

ISSUE 18

Accept in Figure 10 is not correct - INFO response is not expected to contain body.

ISSUE 19

To in Figure 11 does not contain tag.

ISSUE 20

examples contain a value of schemaLocation parameter which is not aligned with https://www.w3.org/TR/xmlschema-0/#schemaLocation stating "The schemaLocation attribute value consists of one or more pairs of URI references, separated by white space. "

           xsi:schemaLocation=
               "urn:ietf:params:xml:ns:EmergencyCallData:control"

Kind regards

Ivo Sedlacek