Subject: [Ecrit] Review of draft-ietf-ecrit-car-crash-20

From: Dan Romascanu <[email-masked]>
Date: Thu, 05 Jan 2017 03:13:58 -0800

Reviewer: Dan Romascanu
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-ecrit-car-crash-20
Reviewer: Dan Romascanu
Review Date: 2017-01-05
IETF LC End Date: 2017-01-06
IESG Telechat date: 2017-01-19

Summary:

It's a good and useful document which needs to be read and understood
together with the eCall document, and other relevant documents from
EC, NENA, APCOT. There is at least one major issue that deserves
discussion and clarification before approval, IMO. 

Major issues:

1. One aspect of the relationship with eCall is unclear to me. 

The Abstract says: 

>  This document is an extension
   of the eCall document, with the primary differences being that
this
   document makes the MSD data set optional and VEDS mandatory, and
adds
   attribute values to the metadata/control object to permit greater
   functionality. 

Then in the Introduction: 

> This document reuses the technical aspects of next-generation pan-
   European eCall (a mandated and standardized system for emergency
   calls by in-vehicle systems within Europe), as described in
   [I-D.ietf-ecrit-ecall].  However, this document specifies a
different
   set of vehicle (crash) data, specifically, the Vehicle Emergency
Data
   Set (VEDS) rather than the eCall Minimum Set of Data (MSD). 

and in Section 9: 

>  This document extends [I-D.ietf-ecrit-ecall] by reusing the call
set-
   up and other normative requirements with the exception that in
this
   document, support for the eCall MSD is OPTIONAL and support for
VEDS
   in REQUIRED. 

First of all it's not clear if by 'eCall document' what it's meant is
the European document or draft-ietf-ecrit-ecall. Second it's not clear
how the two IETF documents, both on standards track relate, when the
status of the MSD and VEDS data sets are different. What would
prevail? The IESG is asked to approve two document, both on standards
track, with different and in this case contradictory content. If I am
a car manufacturer, I would ask myself what support will be mandatory
to implement? Or maybe there are different scenarios where the
different data sets are recommended? But then should not support for
both be mandatory to implement and optional to use, maybe per
geographical area? After all vehicles cross borders, or are
transported / exported over the seas nowadays. 

Minor issues:

1. In the Abstract: 

> ... this document specifies a different set of vehicle (crash)
   data, specifically, the Vehicle Emergency Data Set (VEDS) ...

Actually VEDS is not specified in this document, but by APCO and NENA
and referred by this document. 

2. In section 4: 

>  In the paired model, the IVS uses a Bluetooth link with a
previously-
   paired handset to establish an emergency call

Is Bluetooth only an example, or only one standard way of establishing
a paired communication in the legacy example? I suspect the later - so
I suggest that the text is reformulated in this manner.

3. I am not an expert in this area but I wonder whether the initial
values of the registry in 14.6 are aligned with car manufacturers
standards. For example I am wondering if lamps that change colors
should not be also included. 

4. I am not an expert in this area but I wonder whether the initial
values of the registry in 14.7 are aligned with car manufacturers
standards. For example I am wondering why night-vision capability is
provided only for the front cameras. 

Nits/editorial comments: 

1. I believe that the European eCall requirements documents 16062 and
16072 need to be Informative References. 

2. Add an informative reference for Bluetooth mentioned in Section 4.

3. Section 16 needs to be removed at publication.

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Thu, 5 Jan 2017 15:17:46 +0000

I think the text you have highlighted is confusing.

While car-crash may build on the internet-draft ecall to create another service, the service defined as ecall by EC and by the various European and 3GPP standards does not require or have any dependence on car-crash at all (or indeed any relationship).

I agree this does need to be clearer.

Keith

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Dan Romascanu
Sent: 05 January 2017 11:14
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [Ecrit] Review of draft-ietf-ecrit-car-crash-20

Reviewer: Dan Romascanu

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.

Summary:

It's a good and useful document which needs to be read and understood together with the eCall document, and other relevant documents from EC, NENA, APCOT. There is at least one major issue that deserves discussion and clarification before approval, IMO. 

Major issues:

>  This document is an extension
   of the eCall document, with the primary differences being that this
   document makes the MSD data set optional and VEDS mandatory, and adds
   attribute values to the metadata/control object to permit greater
   functionality. 

   European eCall (a mandated and standardized system for emergency
   calls by in-vehicle systems within Europe), as described in
   [I-D.ietf-ecrit-ecall].  However, this document specifies a different
   set of vehicle (crash) data, specifically, the Vehicle Emergency Data
   Set (VEDS) rather than the eCall Minimum Set of Data (MSD). 

>  This document extends [I-D.ietf-ecrit-ecall] by reusing the call
set-
   up and other normative requirements with the exception that in this
   document, support for the eCall MSD is OPTIONAL and support for VEDS
   in REQUIRED. 

First of all it's not clear if by 'eCall document' what it's meant is the European document or draft-ietf-ecrit-ecall. Second it's not clear how the two IETF documents, both on standards track relate, when the status of the MSD and VEDS data sets are different. What would prevail? The IESG is asked to approve two document, both on standards track, with different and in this case contradictory content. If I am a car manufacturer, I would ask myself what support will be mandatory to implement? Or maybe there are different scenarios where the different data sets are recommended? But then should not support for both be mandatory to implement and optional to use, maybe per geographical area? After all vehicles cross borders, or are transported / exported over the seas nowadays. 

Minor issues:

Actually VEDS is not specified in this document, but by APCO and NENA and referred by this document. 

previously-

Is Bluetooth only an example, or only one standard way of establishing a paired communication in the legacy example? I suspect the later - so I suggest that the text is reformulated in this manner.

3. I am not an expert in this area but I wonder whether the initial values of the registry in 14.6 are aligned with car manufacturers standards. For example I am wondering if lamps that change colors should not be also included. 

4. I am not an expert in this area but I wonder whether the initial values of the registry in 14.7 are aligned with car manufacturers standards. For example I am wondering why night-vision capability is provided only for the front cameras. 

Nits/editorial comments: 

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: Randall Gellens <[email-masked]>
Date: Thu, 5 Jan 2017 11:11:30 -0800

Hi Dan,

Thanks for your review.  Please see in-line.

At 3:13 AM -0800 1/5/17, Dan Romascanu wrote:

>  the European document or draft-ietf-ecrit-ecall.

My understanding is that references are frowned upon in Abstracts, 
otherwise there would be a reference to the IETF eCall draft there. 
I did change "extension of the eCall document" to "extension of the 
IETF eCall document" to try and make this more clear.

>   Second it's not clear

There is no conflict, as the eCall document applies to regions that 
adhere to the E.U. eCall system, and this document applies to other 
regions.  I added the following sentence to the paragraphs in the 
Abstract and Introduction:

    A vehicle designed for multiple regions will
    comply with the document applicable to the region in which it is
    located.

The eCall document already says (in Document Scope):

    Note that 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]), but this
    is out of scope of this document.

>  and referred by this document.

I'll change "specifies" to "specifies use of".

>  I suggest that the text is reformulated in this manner.

Ok, I changed it to "a local link (typically Bluetooth)".

>  should not be also included.

The goal is that the initial values capture values that are widely 
supported by vehicles and likely to be useful to PSAPs.

>  provided only for the front cameras.

The values were picked based on what's most supported, but I will add 
rear and side night-vision to the initial values.

>  16072 need to be Informative References.

EU eCall requirements are referenced in the eCall draft, which this 
draft normatively references, and are not directly used in this 
draft, so I don't see that it's useful to add them here.

>  2. Add an informative reference for Bluetooth mentioned in Section 4.

OK.

>  3. Section 16 needs to be removed at publication.

I'll add a note.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Experience should teach us to be most on our guard to protect liberty
when the government's purposes are beneficent.  Men born to freedom are
naturally alert to repel invasion of their liberty by evil-minded
rulers.  The greatest dangers to liberty lurk in insidious encroachment
by men of zeal, well-meaning but without understanding.
    --Louis D. Brandeis

---

From: Dan Romascanu <[email-masked]>
Date: Thu, 5 Jan 2017 21:53:45 +0200

Hi,

Thanks for the quick answer and for addressing my comments.

adhere to the E.U. eCall system, and this document applies to other
regions.  I added the following sentence to the paragraphs in the Abstract
and Introduction:

I do not believe that this is sufficiently clear. Do you mean here that
this document applies to all regions that do not implement the eCall
system? If so, please say it explicitely.

Also, what does 'comply' mean? Is this about what is implemented in the
software, or about what is activated? Without this clarification, your
usage of MANDATORY and OPTIONAL keywords is fuzzy.

Regards,

Dan

On Thu, Jan 5, 2017 at 9:11 PM, Randall Gellens <[email-masked]>
wrote:

> otherwise there would be a reference to the IETF eCall draft there. I did
> change "extension of the eCall document" to "extension of the IETF eCall
> document" to try and make this more clear.
>
>   Second it's not clear
> There is no conflict, as the eCall document applies to regions that adhere
> to the E.U. eCall system, and this document applies to other regions.  I
> added the following sentence to the paragraphs in the Abstract and
> Introduction:
>
> The values were picked based on what's most supported, but I will add rear
> and side night-vision to the initial values.
>
>
>>
>>  Nits/editorial comments:
>>
> EU eCall requirements are referenced in the eCall draft, which this draft
> normatively references, and are not directly used in this draft, so I don't
> see that it's useful to add them here.
>

---

From: Randall Gellens <[email-masked]>
Date: Fri, 6 Jan 2017 04:54:36 -0800

At 9:53 PM +0200 1/5/17, Dan Romascanu wrote:

>>  There is no conflict, as the eCall document applies to regions 
>> that adhere to the E.U. eCall system, and this document applies to 
>> other regions.  I added the following sentence to the paragraphs 
>> in the Abstract and Introduction:
>
>  I do not believe that this is sufficiently clear. Do you mean here 
> that this document applies to all regions that do not implement the 
> eCall system? If so, please say it explicitely.
>
>  Also, what does 'comply' mean? Is this about what is implemented in 
> the software, or about what is activated? Without this 
> clarification, your usage of MANDATORY and OPTIONAL keywords is 
> fuzzy.

Hi Dan,

On reflection, I've deleted the two added sentences:

The Introduction already says:

    Vehicles
    designed to operate in multiple regions might need to support eCall
    as well as NG-ACN as described here.  A vehicle IVS might determine
    whether to use eCall or ACN by first determining the region or
    country in which it is located (e.g., from a GNSS location estimate
    and/or identity of or information from an MNO).  If other regions
    adopt other data formats, a multi-region vehicle might need to
    support those as well.

I think this text is better than the added sentences, and I agree 
with you that the added text introduced its own ambiguity.

--Randy

>  On Thu, Jan 5, 2017 at 9:11 PM, Randall Gellens 
> <<mailto:[email-masked]>[email-masked]> wrote:
>
>  Hi Dan,
>
> <<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
>  The values were picked based on what's most supported, but I will 
> add rear and side night-vision to the initial values.
>
>
>
>   Nits/editorial comments:
>

-------------- Randomly selected tag: ---------------
The chance of forgetting something is directly proportional
to.....to........uh..............