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

[Alissa Cooper <[e-mail]>]

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.

= Section 7 =

s/Emergency Call Additional Data Blocks registry/Emergency Call Data Types registry/

= Section 9 =

Is this section necessary? It seems superfluous.

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

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

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

= Section 10.2 =

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

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

= Section 12 =

Please move this to the IANA considerations section.

= Section 16  =

s/Emergency Call Additional Data registry/Emergency Call Data Types registry/

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

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

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

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

= Section 19.2 =

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


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.

= Abstract =

s/an INFO package/a SIP INFO package/

= Section 1 =

s/an NG-ACN call/a next-generation ACN call/

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

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

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/

= Section 3 =

s/the right-hand side/the other call leg/

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

s/to indicates/to indicate/

[1] https://www.ietf.org/mail-archive/web/ecrit/current/msg09991.html

= 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]."
   
= Section 10.2 =

s/persistance/persistence/

= Section 10.4 =

s/the IV/the IVS/

= Section 13 =

s/about about/about/

= Section 16.1 =

s/Section 7 and Section 8/Section 9 and Section 10/

s/Gellensm/Gellens/