Re: Review of draft-ietf-ecrit-car-crash-20

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Dan,

Thanks for your review.  Please see in-line.

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

 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.

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

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.



 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.

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


 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.

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

 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.

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


 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.

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:

 1. I believe that the European eCall requirements documents 16062 and
 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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]