Last Call Review of draft-ietf-ecrit-data-only-ea-18

Request Review of draft-ietf-ecrit-data-only-ea
Requested rev. no specific revision (document currently at 22)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2019-09-02
Requested 2019-08-19
Authors Brian Rosen, Henning Schulzrinne, Hannes Tschofenig, Randall Gellens
Draft last updated 2019-08-29
Completed reviews Opsdir Last Call review of -18 by Jürgen Schönwälder (diff)
Secdir Last Call review of -18 by Charlie Kaufman (diff)
Genart Last Call review of -18 by Mohit Sethi (diff)
Opsdir Telechat review of -21 by Jürgen Schönwälder (diff)
Iotdir Telechat review of -21 by Gonzalo Salgueiro (diff)
Secdir Telechat review of -22 by Charlie Kaufman
Genart Telechat review of -21 by Mohit Sethi (diff)
Assignment Reviewer Charlie Kaufman 
State Completed
Review review-ietf-ecrit-data-only-ea-18-secdir-lc-kaufman-2019-08-29
Posted at
Reviewed rev. 18 (document currently at 22)
Review result Has Nits
Review completed: 2019-08-29


I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document defines a new MIME type: 'application/EmergencyCallData.cap+xml' for use primarily by sensors to send alert messages to emergency services providers. It also defines a new Emergency Call Data Type: 'cap' in order to embed this data efficiently in a SIP transaction. I saw no new security issues beyond those already noted for the protocols carrying these messages.

I do have some editorial suggestions:

There is a lot of context that the authors assumed any reader would have that could have been stated in the introduction. I believe from context that the purpose of this new MIME type is to support simple (IoT) sensors that don't want to implement a more heavyweight protocol, but I don't believe that was stated anywhere.

I got the impression that the functionality provided could have been done with existing protocols by sending the CAP message over a SIP session, but that doing so would place an unnecessary burden on simple (IoT) sensors, and that this protocol would be easier for such sensors to implement for the limited cases such sensors need to deal with. If that's true, it should be stated. If not, the purpose of this protocol should be more clearly stated.

These acronyms were used but never defined:


These acronyms were expanded, but not in an easy to find place:

Common Alerting Protocol (CAP)
Public Safety Answering Points (PSAPs)
Emergency Services Routing Proxy (ESRP)

It would be nice to include them in the terminology section, ideally with a reference to the RFC where more information is available.


p17 "security mechanism" -> "security mechanisms"