Thank you very much for your review. The term we use for these kinds of “calls” has changed several times. There really isn’t a great name. In another forum, we’re calling them “non-human-initiated”, but that really isn’t right either. If you press a button and a device sends your location and some medical data, then it IS human initiated. The differentiation that matters is whether there is two way interactive media or not, which also means whether there is a session or not. Most of these “calls” will be from sensors, and really are data-only, and I think the differentiation between data and media is clear and not confusing. But you could have one way, non interactive media signaled with these calls (a surveillance camera for example). The call would be session-less. The camera information would be passed as a URI to an RTSP media stream, so what is passed really is data (the URL) and not the media, but there IS media involved, so “data-only” isn’t great. “Non Interactive” may also not be quite right: If an elevator sends you an alert and also gives responders access to control it, is that interactive? The “call” isn’t, but the name could be misleading. In the end, I don’t think changing the name is worth while. It’s fairly accurate, not confusing. I’d be okay with changing it to “Non-Human-Initiated”, but that has problems also. I will take this discussion back to the work group though, “Authorize” really is the right word. We may be able to authenticate you (using stir for example), but we usually don’t have any authorization mechanism - unless we’re under attack, we take calls from anyone. That’s the nature of emergency calls. In the US, you can get an emergency call from a mobile that has no service. I’ll do the edits for the additional information in the parameter. PIDF-LO is how emergency calls send location. I’ll improve that text. Also will substitute “detects” for “understands” and fix the nits. Brian > On Aug 28, 2019, at 9:38 AM, Mohit Sethi via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Mohit Sethi > Review result: Ready with Issues > > 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 > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > 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. >
