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

[Randall Gellens <[e-mail]>]

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

>  Hi,
>
>  Thanks for the quick answer and for addressing my comments.
>
>  On respect to:
>
>>  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.
>
>  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:

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

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:[e-mail]>[e-mail]> wrote:
>
>  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>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


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The chance of forgetting something is directly proportional
to.....to........uh..............