[Ecrit] Barry Leiba's No Objection on draft-ietf-ecrit-data-only-ea-21: (with COMMENT)

Barry Leiba via Datatracker <noreply@ietf.org> Mon, 24 February 2020 00:48 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: ecrit@ietf.org
Delivered-To: ecrit@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DB63A12EC; Sun, 23 Feb 2020 16:48:56 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ecrit-data-only-ea@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, Allison Mankin <allison.mankin@gmail.com>, draft-ietf-ecrit-data-only-ea@ietf.org, allison.mankin@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.118.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <barryleiba@computer.org>
Message-ID: <158250533653.1160.12882300058392230264.idtracker@ietfa.amsl.com>
Date: Sun, 23 Feb 2020 16:48:56 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/8ELNXUTaR8IM5rYHTg_7LYxMJ4M>
Subject: [Ecrit] Barry Leiba's No Objection on draft-ietf-ecrit-data-only-ea-21: (with COMMENT)
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.29
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Feb 2020 00:48:57 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-ecrit-data-only-ea-21: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this document.  I have only a few editorial comments:

The Abstract strikes me as a bit long — certainly not ridiculously so, but
longer than necessary for an abstract.  Much of the information there, useful
as it be, is stuff for an Introduction, not an Abstract.  Clearly, this is
entirely up to the working group, and this is just a minor comment.  In case
you find it useful, here’s what I would do with the Abstract for this:

NEW
Use of the Internet for emergency calling is described in RFC 6443, 'Framework
for Emergency Calling Using Internet Multimedia’.  In some cases of emergency
calls, the transmission of application data is all that is needed and no
interactive media channel is established — a situation referred to as
non-interactive emergency calls.  This document describes use of a SIP MESSAGE
transaction that includes a container for the data based on the Common Alerting
Protocol (CAP).  That type of emergency request does not establish a session,
distinguishing it from SIP INVITE, which does.  Any device that needs to
initiate a request for emergency services without an interactive media channel
would use the mechanisms in this document. END

— Section 1 —

   Examples of such
   environments includes sensors issuing alerts, or certain types of
   medical monitors.

Nit: Examples “include”.  And plural “examples” needs “and”, not “or”.

   These
   type of interactions

Nit: These “types”

   Non-Interactive emergency calls are similar to regular emergency

In the previous paragraph you didn’t capitalize “interactive”; usage should be
consistent.

   calls in the sense that they require the emergency indications,
   emergency call routing functionality and may even have the same
   location requirements.

The third item isn’t parallel to the first two.

NEW
   calls in the sense that they require the emergency indications,
   they require emergency call routing functionality, and they may
   even have the same location requirements.
END

   This document is concerned with
   citizen to authority "alerts", where the alert

“citizen-to-authority”, as it’s a compound modifier.  But shouldn’t it be
“authority-to-citizen” anyway?

   (a URI is included in the message, which when dereferenced returns
   the CAP message).

This sounds as if it’s the message that’s dereferenced.  This reads better (and
is also in active voice):

NEW
   (the message includes a URI that, when dereferenced, returns
   the CAP message).
END

   alert specific data beyond that available in the CAP message.

Nit: “alert-specific”

— Section 3 —

       2.  Establishing a third-party initiated emergency call

Nit: “third-party-initiated”

   to determine the next hop proxy to route the alert message to.

Nit: “next-hop proxy”x

   relationship between the originator and the receiver, e.g., a PSAP.
   A PSAP, for example, is likely to receive and accept alerts from

The double “for example, PSAP” structure feels odd.  I would just remove “,
e.g., a PSAP” and let the “A PSAP, for example,…” take care of it.

— Section 4.2 —

      given <sender, expires, incidents> combination.  Note that the
      <expires> element is optional and may not be present.

A minor thing that you can ignore if you disagree with: I think “might not be
present” is less likely to be confused with a BCP 14 “MAY” in this sentence
construction.

      Arc-
      bands and ellipses SHOULD be converted to an equivalent polygon.
      3D locations SHOULD be converted to their equivalent 2D forms.

Can they really be made “equivalent”?  Or do we really mean something like this
(also correcting the number-agreement problem in the first sentence)?:

NEW, maybe?
      Arc-
      bands and ellipses SHOULD be converted to polygons with similar
      coverage, and 3D locations SHOULD be converted to 2D forms with
      similar coverage.
END

— Section 5.2 —

   For
   example, a UA includes an alert in a MESSAGE to a PSAP.

Nit: I would say, “For example, suppose a UA includes…”

   A SIP intermediary that requires the UA's alert message in order to
   properly process the transaction may also sends a 425 with an

Nit: “may also send a 425”

   There MUST be no more than one
   AlertMsg-Error code in a SIP response.

I find “MUST” with a negative statement to be awkward, especially when it’s
easily avoided; it’s OK, of course, if you disagree.  I suggest this:

NEW
   There MUST NOT be more than one
   AlertMsg-Error code in a SIP response.
END

   [RFC3262]; or, if that mechanism is not negotiated, it must be

Nit: remove “it”.

— Section 7 —

   The CAP message itself can be sent by-reference
   using this mechanism, as well as any or all of the Additional Data
   blocks that may contain sensor-specific data.

This structure makes the antecedent to “as well as” ambiguous (it looks like
it’s “this mechanism”, but it’s not).  I suggest this (which also removes the
stray hyphen from “by reference”):

NEW
   The CAP message itself can be sent by reference
   using this mechanism, as can any or all of the Additional Data
   blocks that may contain sensor-specific data.
END

— Section 9 —

   Location specific
   threats are not unique to this document

Nit: hyphenate “Location-specific”

   reason, it needs to be possible to refuse to accept alert messages
   from an unknown origin.

Nit: “from unknown origins”

   Note that none of the security mechanism in this document protect

Nit: “mechanisms”

— Section 10.1 —

Please use “media type”, not “MIME type” nor “MIME media type”.

Please check the registration template in RFC 6838, Section 5.6, and align with
it (there are just slight variations that will be easy to sort out).