Re: Review of draft-ietf-ecrit-car-crash-20
Randall Gellens <rg+ietf@randy.pensive.org> Fri, 06 January 2017 12:54 UTC
Return-Path: <rg+ietf@randy.pensive.org>
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 60724129B0C; Fri, 6 Jan 2017 04:54:46 -0800 (PST)
X-Quarantine-ID: <o_JV3tmo4rne>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -5
X-Spam-Level:
X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no
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 o_JV3tmo4rne; Fri, 6 Jan 2017 04:54:45 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id D80EE128AC9; Fri, 6 Jan 2017 04:54:44 -0800 (PST)
Received: from [192.168.202.67] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 6 Jan 2017 04:53:46 -0800
Mime-Version: 1.0
Message-Id: <p06240615d495435a700f@[192.168.202.67]>
In-Reply-To: <CAFgnS4VNkFWbbQy-SBt_Bp=hVvJ=Js-sRW83fNrsnBypE9Yd_Q@mail.gmail.com>
References: <148361483847.20720.1815627449197698164.idtracker@ietfa.amsl.com> <p06240604d4943c43cb3c@192.168.202.67> <CAFgnS4VNkFWbbQy-SBt_Bp=hVvJ=Js-sRW83fNrsnBypE9Yd_Q@mail.gmail.com>
X-Mailer: Eudora for Mac OS X
Date: Fri, 06 Jan 2017 04:54:36 -0800
To: Dan Romascanu <dromasca@gmail.com>
From: Randall Gellens <rg+ietf@randy.pensive.org>
Subject: Re: Review of draft-ietf-ecrit-car-crash-20
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/aC4flldIR5pMNWkqSmCfU6lurw8>
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: Fri, 06 Jan 2017 12:54:46 -0000
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:rg+ietf@randy.pensive.org>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>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..............
- Review of draft-ietf-ecrit-car-crash-20 Dan Romascanu
- RE: [Ecrit] Review of draft-ietf-ecrit-car-crash-… Drage, Keith (Nokia - GB)
- Re: Review of draft-ietf-ecrit-car-crash-20 Randall Gellens
- Re: Review of draft-ietf-ecrit-car-crash-20 Dan Romascanu
- Re: Review of draft-ietf-ecrit-car-crash-20 Randall Gellens