[Ecrit] Christer's review of draft-ietf-ecrit-ecall-15 (excluding Section 15)

[Christer Holmberg <[e-mail]>]

Hi,

Attached is my review of draft-ietf-ecrit-ecall-15. I have not reviewed Section 15.

Note that some of my comments probably apply to draft-ietf-ecrit-car-crash also, so I ask the authors to take that into consideration.

Regards.

Christer

----------

Q1:

In Section 2, I suggest to change the title to "Applicability", because I think that is what is normally used.


Q2:

In Section 2, you should expand "3GPP" and "CEN" on first occurrence. In addition, I think there should be a reference with "3GPP IMS Emergency Calling".


Q3:

In Section 2, the text says:

   "The technical contents of this document also provide a basis for
   reuse and extension for other vehicle-initiated emergency call
   Systems.

   Vehicles designed for multiple regions might need to support eCall
   and other Advanced Automatic Crash Notification (AACN) systems, such
   as described in [I-D.ietf-ecrit-car-crash]."

I don¹t think the text is needed, but if you want to keep it you should explicitly say that it¹s outside the scope of the document.


Q4:

In Section 3, you first describe eCall in general, which is good. But then, in the last paragraph, you suddenly start talking about MIME types. I think you should add another chapter, giving a general overview of what the document does. I guess you can re-use text from the Abstract.


Q5:

In Section 5, I suggest to re-name the title to "MSD Format", or something like that.


Q6:

In Section 6, please add references to the different SIP/MIME header fields (Content-Type, Content-ID etc).


Q7:

In Section 6, the text says:

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

We did agree on this for INFO, but is there a reason for doing this also in non-INFO requests?


Q8:

In Section 6, the text says:

   "Note that in some cases there might be intermediate
   multipart body parts between the top level multipart and the body
   part containing the MSD or metadata/control object."

I have no idea what that text means.


Q9:

In Section 9, I suggest to remove the bullet list. I don¹t really understand why it is needed, and it¹s unclear what "This mechanism" refers to.
IF you want to list requirements associated with carrying control/metadata I think it should be in a separate section.


Q10:

In Section 9, the text says:

   "if the IVS sends a requested MSD in an INFO request and does not receive a SIP
   status message for the INFO request, it resends it; if the PSAP
   requests an MSD and does not receive a SIP status message for the
   INFO request, it resends it.)"

This is basic SIP,  and can be removed. Earlier you mention SIP re-transmission, and that¹s enough. I think you should add the following, though:

   ³Note that, per RFC6086, a 200 OK response to the INFO request only indicates that the receiver has successfully received and accepted the INFO request."


Q11:

In Section 9, the text says:

   "The SIP response codes 600 (Busy Everywhere), 486 (Busy Here), and 603 (Decline) are used when
   the PSAP wants to reject a call but inform the vehicle occupants that
   it is aware of the situation."

Please add a reference to where this is defined.


Q12:

In Section 10.6, please add explicit text that says that multipart is used even if only a single body part is transported. You may even reference the example in RFC 6086. Also add explicit text saying that ³Per RFC 6086, the content disposition value of the multipart MIME is 'info-package', or something like that.


Q13:

In Section 10.6, similar to my earlier comment, I don¹t understand the text about "intermediary body parts".


Q14:

In Section 11, you should add the Content-Disposition SIP header field (with 'info-package' value) to the INFO requests.

Regards,

Christer