Re: [Ecrit] AD evaluation: draft-ietf-ecrit-car-crash-19

[Randall Gellens <[e-mail]>]

Hi Alissa,

Thanks for your review.  Please see inline.

At 1:40 PM -0500 12/7/16, Alissa Cooper wrote:

>  I have reviewed this document in preparation for IETF last call. 
> There are a few items that require discussion before proceeding to 
> LC. I've also included nits that should be resolved together with 
> LC comments or beforehand.
>
>  Substantive comments:
>
>  = Section 6 =
>
>  "The item is registered in the Emergency Call Additional Data
>        registry, as defined in Section 9.1.7 of [RFC7852]"
>
>  Is this supposed to be the Emergency Call Data Types Registry 
> defined in Section 11.1.9 of RFC 7852? Section 9.1.7 does not exist.

Yes, thanks for catching this (text left over from an earlier version 
of the additional-data draft).

>
>  = Section 7 =
>
>  s/Emergency Call Additional Data Blocks registry/Emergency Call 
> Data Types registry/

Thanks.

>  = Section 9 =
>
>  Is this section necessary? It seems superfluous.

I agree it can be deleted.


>  = Section 10 =
>
>  (1) Is there a need to state than an IVS MUST ignore requests from 
> PSAPs containing the child elements defined here if those requests 
> arrive outside of a dialog that the IVS itself initiated? Suppose a 
> rogue or buggy PSAP started calling vehicles and getting them to 
> flash their lights or honk their horns -- seems like a safety 
> problem. This is already implied and is obviously a corner case but 
> given the potential severity I'm wondering if it's worth calling 
> this out explicitly.

We don't want to rule out PSAP call-backs.  A PSAP might need to call 
back a vehicle that initiated an emergency call that was terminated. 
Section 14 explicitly says that the vehicle may decline to carry out 
a request (and suggests failure to authenticate the request as one 
possible reason).  It's reasonable for an IVS implementation to only 
honor requests that come in emergency calls it itself initiated, at 
least in the early years of NG-AACN deployment, but I don't think we 
should mandate that.

>  (2) I think the initial registry contents for lamp, camera, and 
> msg-static should be discussed somewhere in this section.

I added this where each of those actions is listed.


>  = Section 10.1 =
>
>  I don't understand why support for messages would be assumed to be 
> cumulative in the order in which messages end up being registered 
> in the registry. Why isn't the case where a vehicle supports 
> messages 1, 3, and 5 but not 2 and 4 a possible case?

The expectation is that there will be few static messages; there 
isn't a basis for IVS implementations to pick which ones to support, 
especially since it is text that is displayed on a screen, so the 
complexity of only supporting some messages outweighs the cost of 
supporting a set up to a known value.

>  = Section 10.2 =
>
>  (1) lamp-id and lamp-action are not defined anywhere as attributes 
> of a request.

Thanks for catching this.  Those attributes were changed to the more 
generic 'element-id' a while back but this text wasn't updated.

>
>  (2) It seems to me that the static message with msgid=1 and the 
> dynamic message provided here are contradictory. One says that help 
> is not on the way and the other says that it is. Why would a PSAP 
> send both of these messages?

Static message 1 only says that the PSAP can't accept the voice call 
(nothing about sending help or not), so I don't see it as 
contradictory.  Also, it's just an example to show both static and 
dynamic messages.

>  = Section 12 =
>
>  Please move this to the IANA considerations section.

OK.

>  = Section 16  =
>
>  s/Emergency Call Additional Data registry/Emergency Call Data Types registry/

Oops, thanks.

>
>  = Section 16.2  =
>
>  s/Emergency Call Additional Data registry/Emergency Call Data Types registry/
>
>  This section also needs to designate what goes in the 'Data About' column.

Thanks.  I also updated the eCall draft to fill in the 'Data About' value.

>  = Section 16.4 =
>
>  "Because all
>     compliant vehicles are expected to support all static messages
>     translated into all languages supported by the vehicle, it is
>     important to limit the number of such messages."
>
>  Having a registry does not limit the number of messages, strictly 
> speaking. Perhaps this is meant to be inverted -- static message 
> support is provided and the registry is being created to list them 
> because of the expectation that there will be a limited number of 
> them?

The statement is intended to justify the more restrictive rules for 
adding values.  It's not about a registry per se, but rather the 
rules for adding to it.

>  Also, this sort of explanation belongs in Section 10, not here.

I added text to that section.

>  And I think you mean "Specification Required policy," not 
> "Publication Required rules."

Yes, thank you.

>  = Section 19.2 =
>
>  I think RFC 6086 needs to be a normative reference. Should have 
> made the same comment on the ecall document.

Fixed in both drafts.

>  Nits:
>
>  = General =
>
>  The editorial fixes made in response to Ivo's review of the ecall 
> document [1] should also be made here to the extent that the same 
> text has been re-used.

I scoured the document for offending "attach" uses and also made 
Ivo's requests to add "method" in various places to both documents.

>  = Abstract =
>
>  s/an INFO package/a SIP INFO package/

OK

>  = Section 1 =
>
>  s/an NG-ACN call/a next-generation ACN call/

I spelled it out the first time, and added it to the list of 
abbreviations in Section 1.

>  s/sending an INVITE request, receiving an
>     INFO request, etc./sending a SIP INVITE request, receiving a SIP
>     INFO request, etc.

Done for both drafts.

>  = Section 2 =
>
>  I think it would help to note that APCO and NENA are US-based 
> organizations and also to include a note similar to what I 
> suggested for ecall to the effect that the document is specified 
> generically such that the technology may be re-used or extended to 
> suit requirements across jurisdictions.

OK.

>  s/registers the 'VEDS' entry in the Emergency Call Additional Data 
> registry/registers the 'VEDS' entry in the Emergency Call Data 
> Types Registry/
>
>  s/registers a new INFO package/registers a new SIP INFO package/

Fixed globally.

>  = Section 3 =
>
>  s/the right-hand side/the other call leg/

OK.

>  = Section 5 =
>
>  Some of the material in this section has significant overlap with 
> material in Section 2. I would suggest streamlining so that the 
> background info appears in one place or the other but not both.

I edited both sections.  There's a small bit of overlap about NG 
migration left, but I don't think it's a problem, and I don't think 
there's much overlap background left.

>  s/to indicates/to indicate/

Thanks.

>  = Section 8 =
>
>  This sentence is not grammatically correct and should be fixed (in 
> addition to fixing the "attached" language):
>
>  "A next-generation In-Vehicle System (IVS) initiates an NG-ACN call
>     with a SIP INVITE using one of the SOS sub-services
>     "SOS.ecall.automatic" or "SOS.ecall.manual" in the Request-URI,
>     standard sets of crash data and capabilities data encoded in
>     standardized and registered formats, attached as additional data
>     blocks as specified in Section 4.1 of [RFC7852]."

I rewrote it.

>    = Section 10.2 =
>
>  s/persistance/persistence/

Oops, thanks.

>  = Section 10.4 =
>
>  s/the IV/the IVS/

Thanks.

>  = Section 13 =
>
>  s/about about/about/

Thanks.

>  = Section 16.1 =
>
>  s/Section 7 and Section 8/Section 9 and Section 10/

Thanks.

>  s/Gellensm/Gellens/

Oops, thanks.


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Computers make very fast, very accurate mistakes.