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

[Brian Rosen <[e-mail]>]

-22 addresses your comments, I hope.
https://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-22

Brian

> On Feb 23, 2020, at 7:48 PM, Barry Leiba via Datatracker <[e-mail]> wrote:
> 
> 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).
> 
> 
>