I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ecrit-data-only-ea-18 Reviewer: Mohit Sethi Review Date: 2019-08-28 IETF LC End Date: 2019-09-02 IESG Telechat date: Not scheduled for a telechat Summary: This draft is almost ready for publication, but has some issues that concern me. The most important one is the choice of the term "data-only". Major issues: I am unsure why the authors and the WG chose the term data-only emergency call? First, I thought that it is referring to a unidirectional call but that isn't the case here. Also, aren't interactive RTP sessions also essentially composed of data packets? Perhaps notification-only and/or non-interative emergency calls could be considered as an alternative. Minor issues: The text says "A PSAP, for example, is likely to receive and accept alerts from entities it cannot authorize.". Is authorize the correct word? did you mean authenticate? You need to authenticate before you authorize. parameter: MAY contain additional information. Is it ASCII? How long can it be? I presume that the CAP has some clearler guideline. At least you could write that the CAP restrictions apply The text says something about PIDF-LO structure referenced by? I am not sure what is meant here? Perhaps some more text here would help the reader understand better. The text says "A SIP intermediary can also reject an alert it receives from a User Agent (UA) when it understands that the provided alert is malformed.". Perhaps detects is better choice than understand. It cannot understand something that is malformed. Nits/editorial comments: citizen/individual -> citizens/individuals Sending a non-interactive call containing only data toward a -> only data towards a Figures 1 and 2 could have more info. Is it a HTTP or SIP 200 (OK)? and the recipient using HTTPS to retrieve the data. -> and the recipient uses HTTPS to retrieve the data.