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

"Drage, Keith (Nokia - GB)" <> Thu, 05 January 2017 15:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20628129B53; Thu, 5 Jan 2017 07:18:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qzkaB_RvIJrS; Thu, 5 Jan 2017 07:18:03 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 546F01289C4; Thu, 5 Jan 2017 07:18:00 -0800 (PST)
Received: from (unknown []) by Websense Email Security Gateway with ESMTPS id 935F112F9125D; Thu, 5 Jan 2017 15:17:55 +0000 (GMT)
Received: from ( []) by (GMO-o) with ESMTP id v05FHtp5032435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Jan 2017 15:17:58 GMT
Received: from ( []) by (GMO) with ESMTP id v05FHNB5030626 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jan 2017 15:17:51 GMT
Received: from ([]) by ([]) with mapi id 14.03.0301.000; Thu, 5 Jan 2017 16:17:48 +0100
From: "Drage, Keith (Nokia - GB)" <>
To: Dan Romascanu <>
Subject: RE: [Ecrit] Review of draft-ietf-ecrit-car-crash-20
Thread-Topic: [Ecrit] Review of draft-ietf-ecrit-car-crash-20
Thread-Index: AQHSZ0Tk29gVnjfUIE+7CxWknwLodaEp55Rw
Date: Thu, 05 Jan 2017 15:17:46 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>, "" <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Jan 2017 15:18:06 -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.


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

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


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


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

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

Ecrit mailing list