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

From: Alissa Cooper <[email-masked]>
Date: Wed, 7 Dec 2016 13:40:43 -0500

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/

---

From: Randall Gellens <[email-masked]>
Date: Thu, 15 Dec 2016 16:17:27 -0800

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

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

Thanks.

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

>  (1) lamp-id and lamp-action are not defined anywhere as attributes 

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.

>  Please move this to the IANA considerations section.

OK.

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

Oops, thanks.

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

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

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

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

OK

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

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

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

Fixed globally.

>  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):
>

I rewrote it.

>  s/persistance/persistence/

Oops, thanks.

>  s/the IV/the IVS/

Thanks.

>  s/about about/about/

Thanks.

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

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 16 Dec 2016 09:14:04 -0500

Thanks Randy. I think this is ready for last call now. I have a couple of comments below that can be resolved together with last call comments.

> On Dec 15, 2016, at 7:17 PM, Randall Gellens <[email-masked]> wrote:
> 
>> = Section 10.1 =
>> 

It would be helpful to include a sentence similar to the above in the document.

> contradictory.  

I guess when I read “We will help you as soon as possible” that sounds to me like it could be a long time from now, which is different from “Help is on the way.” But I see how others might interpret the first one differently.

Alissa

---

From: Randall Gellens <[email-masked]>
Date: Fri, 16 Dec 2016 07:40:16 -0800

At 9:14 AM -0500 12/16/16, Alissa Cooper wrote:

>  Thanks Randy. I think this is ready for last call now. I have a 
> couple of comments below that can be resolved together with last 
> call comments.
>

Happy to add text as a Last Call comment.

>  I guess when I read "We will help you as soon as possible" that 
> sounds to me like it could be a long time from now, which is 
> different from "Help is on the way." But I see how others might 
> interpret the first one differently.

I will ask the NENA PSAP OPS committee to review that static message 
and suggest improved wording.

-------------- Randomly selected tag: ---------------
I detest life-insurance agents; they always argue that I shall some
day die, which is not so.
          --Stephen Leacock (1869-1944)
               _Literary Lapses_ (1910)
                 (Insurance up to Date)