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

Dan Romascanu <dromasca@gmail.com> Thu, 05 January 2017 19:53 UTC

Return-Path: <dromasca@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D41129601; Thu, 5 Jan 2017 11:53:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqzIWByUQUtc; Thu, 5 Jan 2017 11:53:47 -0800 (PST)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47A691295F9; Thu, 5 Jan 2017 11:53:47 -0800 (PST)
Received: by mail-qk0-x22a.google.com with SMTP id a20so54752762qkc.1; Thu, 05 Jan 2017 11:53:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CWSEmcO15QnAGS0vUIq9UlHGkQ9Q9NEeOVLzflun/GM=; b=jUCoNtIt619o1juOirFsGNGb6KFiOcUpFnY/7O1RNwnBmecM2QdhUkqWI2KThG6q2L X1oS+x2n95uZDM3ZjqQnOLcbGUeDRghe7TXw+q+WmnkxsfpEAKInt4dJOQjX2Xn1M4Fc 1joxwNjN5UbcvfksEfW2NoHf/djULS6OgcZRdM499gz0C44WCYYx38C+nP4//jd7WBJI hHZ4qXCQrTBp5JV3/PrQoVlcw0qVISgytYvPD3zVfrGrWFVes45vYrOhzKumb03bopjs shhFvctChdufjC9YIAsUPmKKQbjsi6Z17FcmEfRpaIomod+zBvyREDHRcElKzQnrXvKo iQog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CWSEmcO15QnAGS0vUIq9UlHGkQ9Q9NEeOVLzflun/GM=; b=JnJObHEgdakdPu1dWsIExYZzsiwM9nZAsinwWS4LfPfnHTHI07xqkJGMsO5zezr8+o j80NbBgTmz4KJpG/QbdtjuH4J2vF8th8SKiuAqpNXIxu5KJeS6YD1HfihnUq9PKO7HuW Aiyp4nmAnOTS4ALrl/IoB9GDYZNxxELW6WPLXkXUUV34js6VAfuZCTu74k1uvCG55Xoo gyX7FR8a44gHWZLfmyvkF/sUi2ry8xumvJrOxm8C6PG7buh9Vg8TiKmg48V17RRowkZx v+5degE1FbhgLil9k1eXId6TjZxawAU98fLc33vdR0THf9Iq1Tg5H1dysgNHGuCsZsVI dkSQ==
X-Gm-Message-State: AIkVDXJZqnqhmkKsuo2MUgctJjc74CTEFo4hg5xE5JLDZMz1vjY1wKRTa1a5yrX1AwCi8ilynbiYBn0hTPxpqA==
X-Received: by 10.55.187.70 with SMTP id l67mr47270059qkf.43.1483646026191; Thu, 05 Jan 2017 11:53:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.40.114 with HTTP; Thu, 5 Jan 2017 11:53:45 -0800 (PST)
In-Reply-To: <p06240604d4943c43cb3c@192.168.202.67>
References: <148361483847.20720.1815627449197698164.idtracker@ietfa.amsl.com> <p06240604d4943c43cb3c@192.168.202.67>
From: Dan Romascanu <dromasca@gmail.com>
Date: Thu, 5 Jan 2017 21:53:45 +0200
Message-ID: <CAFgnS4VNkFWbbQy-SBt_Bp=hVvJ=Js-sRW83fNrsnBypE9Yd_Q@mail.gmail.com>
Subject: Re: Review of draft-ietf-ecrit-car-crash-20
To: Randall Gellens <rg+ietf@randy.pensive.org>
Content-Type: multipart/alternative; boundary=94eb2c042fb25d17f405455e42a9
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/TNOFc3ZLqy5Br9YyIueXLFzViZU>
Cc: gen-art <gen-art@ietf.org>, draft-ietf-ecrit-car-crash.all@ietf.org, ietf <ietf@ietf.org>, ecrit@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jan 2017 19:53:50 -0000

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.

Regards,

Dan


On Thu, Jan 5, 2017 at 9:11 PM, Randall Gellens <rg+ietf@randy.pensive.org>;
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>;.
>>
>>  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
>