Re: [Gen-art] Genart last call review of draft-ietf-ecrit-data-only-ea-18

Brian Rosen <br@brianrosen.net> Wed, 28 August 2019 15:53 UTC

Return-Path: <br@brianrosen.net>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083DD12018D for <gen-art@ietfa.amsl.com>; Wed, 28 Aug 2019 08:53:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Drkip6GrMInj for <gen-art@ietfa.amsl.com>; Wed, 28 Aug 2019 08:53:41 -0700 (PDT)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0AC61201E0 for <gen-art@ietf.org>; Wed, 28 Aug 2019 08:53:40 -0700 (PDT)
Received: by mail-qk1-x732.google.com with SMTP id f10so171015qkg.7 for <gen-art@ietf.org>; Wed, 28 Aug 2019 08:53:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Z0WgX5Urn5J7fimHhebnwGGQO130bhyoi1ZJBTaMHAA=; b=bTk7fTcGO7FXLURfS2zFipLIynsalw7umPBu6TXrrl4l/U7/IzTw9BOX11mJmK7b7D i8ENo89FNvs4WaspUlo3D0uBPBo6lTfHm76RI5oM+X1sJcVt2z9NBAmXFCbbSv25tZ1s dIYNOVqZ/dZS7f9x7N0W3yq/ANGwBAcOwWLipE+BAFoUUIxVUOOSfaGleVv4MLngeLmE 4KjnP8LLbPIrd/q4CtAekRTxRJcVKiEqhWtQklGYpeFHA1s4luFJcZ937+4fr23+mR+G /52z9V/6RbxuF6QbMliuB+mm7gOIZkhH0yqg3Acr/DhW3+4JYryauYghCuWk0p7vPHTJ qjPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Z0WgX5Urn5J7fimHhebnwGGQO130bhyoi1ZJBTaMHAA=; b=NnSJWF6EeddxMjyVDWP+VhuqU0XZS6XkrXcgEPMS4yA1om1f/toscLdMBab8E8cCsk qk4wYZ8IKOqAXDpXSfnArT5QSacqwFCJ4pfV0sfte1je4YiLFVokGWcYAmiwASCpCh3d g9w9LZXGGM/d5U0sQSn2rY4qadpdKjhJB+BkAht42pRJ/m1MwXkXvyvf6cnG6FyPXRZu zVwJ6MyVKh0oh63am6iBizAS9K0GG6hOUDB2B/oiuFJ0RrUzpBrT6sVRis1xFv9Yf7fq PGkmWV1zTbPeTPoFwe2E3ZVBPyw8E0xS59vcE5An6vVdvk5aS0tQqV5Qc4OTw8EYYJE2 x90g==
X-Gm-Message-State: APjAAAU2QXqVBxB57coZRYvMaZV2jNh1kLnUjtxHGOVv0NLJbsdJL8R1 fGIgpoMTGnqooy+SBUbvoSdxxA==
X-Google-Smtp-Source: APXvYqxvocaDMBDcDfFQIZUz5WvdQOpV9aImsqRj4uy2uVGl3H+nnR+b8i6arzDfE131J5h9MC65HA==
X-Received: by 2002:a37:6390:: with SMTP id x138mr4753296qkb.222.1567007619886; Wed, 28 Aug 2019 08:53:39 -0700 (PDT)
Received: from brians-mbp-2369.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id x28sm1480517qtk.8.2019.08.28.08.53.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Aug 2019 08:53:39 -0700 (PDT)
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>
X-Mailer: Apple Mail (2.3445.104.11)
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
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Aug 2019 15:53:44 -0000

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@ietf.org> 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.
>