[Ecrit] AD evaluation: draft-ietf-ecrit-car-crash-19

Alissa Cooper <alissa@cooperw.in> Wed, 07 December 2016 18:40 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6415B1296AD for <ecrit@ietfa.amsl.com>; Wed, 7 Dec 2016 10:40:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=0eO4a3kz; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=Phtg8ACU
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 dhGMHN0infst for <ecrit@ietfa.amsl.com>; Wed, 7 Dec 2016 10:40:45 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4767E129528 for <ecrit@ietf.org>; Wed, 7 Dec 2016 10:40:45 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 8CAD820FD8 for <ecrit@ietf.org>; Wed, 7 Dec 2016 13:40:44 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 07 Dec 2016 13:40:44 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=4F5JY5TuZYh9oa6s3XmxiZhEvJU=; b=0eO4a3 kzONRa7e7ea+/PqZ0qGxse9gVJUKISnyVanVipODaCrowuEz8jZdjjloRYSoHByD v/bTzbBVHLzj7FauSNlvPrE0CIWHTvxeqiqAM4Km18yBWUONeMHRC6GSissWv97M 8ZuyrydPZhkEevywZjaqKGXdcr7UMx/2PdKf8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=4F5JY5TuZYh9oa 6s3XmxiZhEvJU=; b=Phtg8ACU+5bGO4mgrlhB+W3jXPsgIAkXnbvg5crYMraAd1 skNX7qphsA+BMZsO6hJr1Yevqq2jd7w81uwnkti5Go05v0QzNiO11sVc8gQVvBhv MbTPh+KfQpHKVcpp1jzlQRiVZtSDyTZYwhscJ81Cf6+vE7JL1qdvAONLVjQtU=
X-ME-Sender: <xms:rFdIWI9vM6IWUbsc7pcGkIgr15YzqgBqJO-IYCDT3VXpa97Bj8WzBQ>
X-Sasl-enc: ULwkt6wO0Q7X4AyxcqOCk1hIo6ehS9NNBAmbNNWZsBI9 1481136044
Received: from alcoop-m-mx19.fios-router.home (pool-108-48-166-97.washdc.fios.verizon.net [108.48.166.97]) by mail.messagingengine.com (Postfix) with ESMTPA id 554847E7A5 for <ecrit@ietf.org>; Wed, 7 Dec 2016 13:40:44 -0500 (EST)
From: Alissa Cooper <alissa@cooperw.in>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <8079F7B1-F7D3-4250-B453-80B01AD92EC7@cooperw.in>
Date: Wed, 07 Dec 2016 13:40:43 -0500
To: Emergency Context Resolution with Internet Technologies Discussion List <ecrit@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/1Oi7jnsCkrkkRGuoKmCTQkUcWcY>
Subject: [Ecrit] AD evaluation: draft-ietf-ecrit-car-crash-19
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2016 18:40:47 -0000

I have reviewed this document in preparation for IETF last call. There are a few items that require discussion before proceeding to LC. I’ve also included nits that should be resolved together with LC comments or beforehand.

Substantive comments:

= Section 6 =

"The item is registered in the Emergency Call Additional Data
      registry, as defined in Section 9.1.7 of [RFC7852]"

Is this supposed to be the Emergency Call Data Types Registry defined in Section 11.1.9 of RFC 7852? Section 9.1.7 does not exist.

= Section 7 =

s/Emergency Call Additional Data Blocks registry/Emergency Call Data Types registry/

= Section 9 =

Is this section necessary? It seems superfluous.

= Section 10 =

(1) Is there a need to state than an IVS MUST ignore requests from PSAPs containing the child elements defined here if those requests arrive outside of a dialog that the IVS itself initiated? Suppose a rogue or buggy PSAP started calling vehicles and getting them to flash their lights or honk their horns -- seems like a safety problem. This is already implied and is obviously a corner case but given the potential severity I'm wondering if it's worth calling this out explicitly.

(2) I think the initial registry contents for lamp, camera, and msg-static should be discussed somewhere in this section.

= Section 10.1 =

I don't understand why support for messages would be assumed to be cumulative in the order in which messages end up being registered in the registry. Why isn't the case where a vehicle supports messages 1, 3, and 5 but not 2 and 4 a possible case?

= Section 10.2 =

(1) lamp-id and lamp-action are not defined anywhere as attributes of a request. 

(2) It seems to me that the static message with msgid=1 and the dynamic message provided here are contradictory. One says that help is not on the way and the other says that it is. Why would a PSAP send both of these messages?

= Section 12 =

Please move this to the IANA considerations section.

= Section 16  =

s/Emergency Call Additional Data registry/Emergency Call Data Types registry/

= Section 16.2  =

s/Emergency Call Additional Data registry/Emergency Call Data Types registry/

This section also needs to designate what goes in the 'Data About' column.

= Section 16.4 =

"Because all
   compliant vehicles are expected to support all static messages
   translated into all languages supported by the vehicle, it is
   important to limit the number of such messages."

Having a registry does not limit the number of messages, strictly speaking. Perhaps this is meant to be inverted -- static message support is provided and the registry is being created to list them because of the expectation that there will be a limited number of them? 

Also, this sort of explanation belongs in Section 10, not here. 

And I think you mean "Specification Required policy," not "Publication Required rules."

= Section 19.2 =

I think RFC 6086 needs to be a normative reference. Should have made the same comment on the ecall document.


Nits:

= General =

The editorial fixes made in response to Ivo's review of the ecall document [1] should also be made here to the extent that the same text has been re-used.

= Abstract =

s/an INFO package/a SIP INFO package/

= Section 1 =

s/an NG-ACN call/a next-generation ACN call/

s/sending an INVITE request, receiving an
   INFO request, etc./sending a SIP INVITE request, receiving a SIP
   INFO request, etc.

= Section 2 =

I think it would help to note that APCO and NENA are US-based organizations and also to include a note similar to what I suggested for ecall to the effect that the document is specified generically such that the technology may be re-used or extended to suit requirements across jurisdictions. 

s/registers the 'VEDS' entry in the Emergency Call Additional Data registry/registers the 'VEDS' entry in the Emergency Call Data Types Registry/

s/registers a new INFO package/registers a new SIP INFO package/

= Section 3 =

s/the right-hand side/the other call leg/

= Section 5 =

Some of the material in this section has significant overlap with material in Section 2. I would suggest streamlining so that the background info appears in one place or the other but not both.

s/to indicates/to indicate/

[1] https://www.ietf.org/mail-archive/web/ecrit/current/msg09991.html

= Section 8 =

This sentence is not grammatically correct and should be fixed (in addition to fixing the "attached" language):

"A next-generation In-Vehicle System (IVS) initiates an NG-ACN call
   with a SIP INVITE using one of the SOS sub-services
   "SOS.ecall.automatic" or "SOS.ecall.manual" in the Request-URI,
   standard sets of crash data and capabilities data encoded in
   standardized and registered formats, attached as additional data
   blocks as specified in Section 4.1 of [RFC7852]."
   
= Section 10.2 =

s/persistance/persistence/

= Section 10.4 =

s/the IV/the IVS/

= Section 13 =

s/about about/about/

= Section 16.1 =

s/Section 7 and Section 8/Section 9 and Section 10/

s/Gellensm/Gellens/