Last Call Review of draft-ietf-ecrit-data-only-ea-18
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
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.
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.