Last Call Review of draft-ietf-ecrit-data-only-ea-18
review-ietf-ecrit-data-only-ea-18-secdir-lc-kaufman-2019-08-29-00

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:

SIP
CID
LoST

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.

Typo:

p17 "security mechanism" -> "security mechanisms"

 --Charlie