[Ecrit] AD evaluation: draft-ietf-ecrit-ecall-20

Alissa Cooper <alissa@cooperw.in> Tue, 06 December 2016 10:32 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 CD7CE129FCE for <ecrit@ietfa.amsl.com>; Tue, 6 Dec 2016 02:32:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=gflJ3f5N; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=BZPYMYhn
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 ZilSqXBYm25l for <ecrit@ietfa.amsl.com>; Tue, 6 Dec 2016 02:31:58 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77EAD129FC6 for <ecrit@ietf.org>; Tue, 6 Dec 2016 02:31:57 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 03FA6206DA for <ecrit@ietf.org>; Tue, 6 Dec 2016 05:31:53 -0500 (EST)
Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Tue, 06 Dec 2016 05:31:53 -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=kFeTniNPd2WHJKdRk3aObhJu4uc=; b=gflJ3f 5NCCdkwtOCeX5mCHbBxWdqZD732hO7XeBEYnIW3I/LiocbljREnAkt3C7HAN1wNb qRx8fV/eIiiYU4skGZQGVlo3VMo1P1Hi722BrORxYWgWyH6YUkHU8OF5CJzFxqsc +sSZQ44iXijEUpshaFczjVqdXIkx9dlg0Byrc=
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=kFeTniNPd2WHJK dRk3aObhJu4uc=; b=BZPYMYhnP/3xfmWx4KyvnWmSDGO5ySCymxcrzX/7u/azW3 cqSWDIMMh1nmkVLsTkQFDevyLq99GDBkWn1/ihkIqYwybTjuoRmw7u2v6srHFxTp QxXBUH3JW+uojOM7J+xXKIaZCIOHet7UJ3bkYvzTg09hmgFkMUOEUHOBti86M=
X-ME-Sender: <xms:mJNGWGRIS4NZMA2H8vETAKmYxfogAB3c0fswhqqzuj6BNIuhIVQ8mg>
X-Sasl-enc: Hsn/8s4DcwGqRRD+p6S7BDMIc+vwrwyfb9AuUVvdyt8u 1481020312
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 B371524753 for <ecrit@ietf.org>; Tue, 6 Dec 2016 05:31:52 -0500 (EST)
From: Alissa Cooper <alissa@cooperw.in>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <97277796-68FC-4967-85B0-3EAE9173DC93@cooperw.in>
Date: Tue, 06 Dec 2016 05:31:52 -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/O6ia6wlxw9J8o_Zo-hxCa7Vp8rU>
Subject: [Ecrit] AD evaluation: draft-ietf-ecrit-ecall-20
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: Tue, 06 Dec 2016 10:32:01 -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 requiring attention before issuing IETF:

= Section 5 =

(1) Since the CEN specifications are not publicly available without paying a fee (as far as I could tell), it would help to provide an overview of what fields are included in the MSD. Otherwise it is difficult to do a complete security/privacy analysis of what is being specified in this document.

= Section 9.1.3.1 =

(1) msgid is underspecified. What is it supposed to be used for? Why is it Conditional?

(2) For supported-values, requested-state, and element-ID, what is the expectation about where and how the permitted values will be specified?

= Section 10 =

I think this section should actually be a subsection of Section 15. IANA needs to register this INFO package and therefore the registration needs to be in the IANA considerations section. Also, documents don't typically reference themselves unless the text is part of an IANA registration.

= Section 12 =

The paragraph that begins "Data received from external sources inherently carries implementation risks ..." seems generic and not specific in any way to this specification. Could you elaborate on the specific threats introduced by this specification and specific guidance to mitigate those threats?

= Section 15 =

"This document formalizes the "EmergencyCallData" media (MIME) subtype
   tree.  This tree is used only for content associated with emergency
   communications.  New subtypes in this tree can be registered by the
   IETF or by other standards organizations working with emergency
   communications, using the "Specification Required" rule, which
   implies expert review.  The designated expert is the ECRIT working
   group."

I reviewed the thread on the media-types list, and I think this text is unclear and needs some fixes:

(1) Instead of saying this "formalizes" the tree, I think the text needs to be explicit that it is registering a new subtree rooted at application/EmergencyCallData.

(2) If you intend for the rules for this subtree to mirror the rules for the standards tree specified in RFC 6838, albeit limiting registrants to emergency-services-related SDOs, then the language used there to describe the registration procedures should be copied.

(3) I think the procedure of specifying the WG as the designated expert is not the most effective choice. It introduces an extra round of triage to find a reviewer when a request comes in, and relies on the perpetual existence of the WG. It's fine if you want the IESG to designate multiple experts or even setup a list with a pool of experts to serve as DEs (neither of which need to be specified in the document), but either of those would be preferable to designating the WG as the expert.

= Section 15.1 =

A description needs to be provided for the registration of urn:service:test.sos.ecall.

= Section 15.2 =

"In general, it is acceptable for the data to be unprotected while briefly in
      transit within the Mobile Network Operator (MNO); the MNO is
      trusted to not permit the data to be accessed by third parties."

This does not seem consistent with Sections 9 and 10 of RFC 7852, where TLS is listed as a SHOULD-level requirement due to legacy deployed bases and the priority for calls to be completed in emergency situations, not because of any sort of trust relationship. I think this text needs to be revised to be consistent with RFC 7852.

= Sections 15.4 and 15.5 =

I think you mean Emergency Call Data Types registry as opposed to Emergency Call Data Blocks registry (the latter does not exist). Also note that the Data Types registry has a 'Data About' column that needs to be filled in for these two entries.

I would also recommend fixing all the other references in the document to the Emergency Call Data Blocks registry.

= Section 19 =

Why are EN_16072 and TS22.101 listed as normative, but TS24.229 is listed as informative? I suspect they could all be informative, although I do not have access to EN_16072.


Nits that can be resolved in the next rev (preferably) or together with IETF LC comments:

= Abstract and Section 2 =

Since the IETF defines standards for the big-I Internet, I think it would help to make a clarification similar to the following in the abstract and in Section 2:

"Although this specification is designed to meet the requirements of European next-generation eCall, it is specified generically such that the technology may be re-used or extended to suit requirements across jurisdictions (see, e.g., draft-ietf-ecrit-car-crash)."

Section 2 doesn't quite say this but I think it's important enough to note specifically there and in the abstract.

= Section 3 = 

s/(both of which are registered in Section 15)/(both of which are registered in Section 15)./

= Section 5 =

I think it would help to explain why support for the XML encoding of MSD is not being specified here.

= Section 8 =

You need to explain what CS-eCall is and expand the acronym on first use.

= Section 9.1.1.2 =

The reason codes should be defined and explained here in the body of the document and references from the IANA considerations section, not defined for the first time there.

= Section 9.1.3.1 =

s/persistance/persistence/

= Section 14 =

s/@success='false"/@success="false"/

= Section 15 =

I don't understand why the intro to this section contains the media type subtree registration, rather than having that in its own subsection like all the other subsections of Section 15.

= Section 15.2 and 15.3 =

"Sections 7 and Section 8 of [RFC7852] contain more discussion."

I think you mean Sections 9 and 10.