Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Brian Rosen <br@brianrosen.net>
In-Reply-To: <156699952808.32349.1850578807441184126@ietfa.amsl.com>
Date: Wed, 28 Aug 2019 11:53:37 -0400
Cc: gen-art@ietf.org, draft-ietf-ecrit-data-only-ea.all@ietf.org,
 ietf@ietf.org, ecrit@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <B02DB366-B5FC-4816-8A8D-3862068885E8@brianrosen.net>
References: <156699952808.32349.1850578807441184126@ietfa.amsl.com>
To: Mohit Sethi <mohit.m.sethi@ericsson.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/3DTeb_kq-7eduhUCOOqYbk61mA4>
Subject: Re: [Gen-art] Genart last call review of
 draft-ietf-ecrit-data-only-ea-18
Precedence: list

Thank you very much for your review.

The term we use for these kinds of =E2=80=9Ccalls=E2=80=9D has changed =
several times.  There really isn=E2=80=99t a great name.
In another forum, we=E2=80=99re calling them =E2=80=9Cnon-human-initiated=E2=
=80=9D, but that really isn=E2=80=99t 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.=20
Most of these =E2=80=9Ccalls=E2=80=9D 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 =E2=80=9Cdata-only=
=E2=80=9D isn=E2=80=99t great.

=E2=80=9CNon Interactive=E2=80=9D 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 =E2=80=9Ccall=E2=80=9D isn=E2=80=99t, but =
the name could be misleading.

In the end, I don=E2=80=99t think changing the name is worth while.  =
It=E2=80=99s fairly accurate, not confusing.  I=E2=80=99d be okay with =
changing it to =E2=80=9CNon-Human-Initiated=E2=80=9D, but that has =
problems also.  I will take this discussion back to the work group =
though,

=E2=80=9CAuthorize=E2=80=9D really is the right word.  We may be able to =
authenticate you (using stir for example), but we usually don=E2=80=99t =
have any authorization mechanism - unless we=E2=80=99re under attack, we =
take calls from anyone.  That=E2=80=99s the nature of emergency calls.  =
In the US, you can get an emergency call from a mobile that has no =
service.

I=E2=80=99ll do the edits for the additional information in the =
parameter.  PIDF-LO is how emergency calls send location.  I=E2=80=99ll =
improve that text.  Also will substitute =E2=80=9Cdetects=E2=80=9D for =
=E2=80=9Cunderstands=E2=80=9D and fix the nits.


Brian


> On Aug 28, 2019, at 9:38 AM, Mohit Sethi via Datatracker =
<noreply@ietf.org> wrote:
>=20
> Reviewer: Mohit Sethi
> Review result: Ready with Issues
>=20
> 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.
>=20
> For more information, please see the FAQ at
>=20
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>=20
> 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
>=20
> 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".
>=20
> 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?
>=20
> Perhaps notification-only and/or non-interative emergency calls could =
be
> considered as an alternative.
>=20
> 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.
>=20
> 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
>=20
> 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.
>=20
> 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.
>=20
> Nits/editorial comments:
>=20
> 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.
>=20