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

[Randall Gellens <[e-mail]>]

Hi Christer,

Thanks for your review.  Please see initial answers (before I've 
edited the draft) below.

--Randy

At 6:44 PM +0000 10/11/16, Christer Holmberg wrote:

>  Regarding Q4, I mean "add another PARAGRAPH" :)
>
>  From: Ecrit [mailto:[e-mail]] On Behalf Of Christer Holmberg
>  Sent: 11 October 2016 21:38
>  To: [e-mail]
>  Subject: [Ecrit] Christer's review of draft-ietf-ecrit-ecall-15 
> (excluding Section 15)
>
>  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.

I've always used "Document Scope" for this material (e.g., see RFC 7852).


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

Good suggestion, thanks, I'll add these.

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

I think the first sentence helps explain the expansion items (e.g., 
used by the car-crash draft), and the second was added by request of 
Keith a year or two ago; I'm happy to reword both sentences to make 
it more clear that this is background info.


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

I see your point.  I'll add another paragraph saying what the draft 
does, to provide a smoother transition into the one about the MIME 
types.


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

What is your concern with the current title?  To me, "Vehicle Data" 
is more general and hence easier to understand for someone who 
doesn't know what an MSD is.  The text explains that the data is 
called an MSD.  How about if I add "(MSD)" to the title?  That way, 
someone who knows they are looking for the MSD info can find it, and 
someone who doesn't know what an MSD is will know what the section is 
about.



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

We have multiple references to RFC 7852.  Do you think we need to 
also reference RFC 3261 for Call-Info and RFC 2045 and/or RFC 2392 
for Content-ID and RFC 2045 for Content-Type and Content-Disposition?


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

I suspect so, and it's the same reason: so that Content-ID is valid. 
(In reality, I can't imagine that an MSD would be the only body part 
in an initial INVITE, but I think we need to say so just in case.)


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

It's just trying to note that there might be multiple levels of 
multipart.  I'll reword this to make it simpler.


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

I think you're right that the bullet list and some surrounding text 
can be deleted.


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

I'm happy to delete the text after "Normal SIP retransmission handles 
non-receipt of requested data".  I agree it isn't needed.

Is there specific text that you think is potentially confusing and 
hence needs the note about the semantics of a 200 OK?


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

I'll reword this text.


>  Q12:
>
>  In Section 10.6, please add explicit text that says that multipart 
> is used even if only a single body part is transported.

I'll add text to make it more explicit.

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

We had an email discussion about this some weeks back, and Paul 
pointed out that it wasn't always correct for the top level multipart 
to have a Content-Disposition of INFO-Package.

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

I'll fix this as above.

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

In the email discussion, Paul said it was better to leave it off.


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The Pledge of Allegiance says `liberty and justice for all'.  Which part
of `all' don't you understand?         --Rep. Pat Schroeder (D) Colorado