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

[Alissa Cooper <[e-mail]>]

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.