Subject: [Ecrit] Barry Leiba's Discuss on draft-ietf-ecrit-data-only-ea-21: (with DISCUSS and COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Sun, 23 Feb 2020 12:05:39 -0800

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

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for this document.  I have a very small ABNF issue I'd like to discuss,
and which should be very easy to sort out one way or another:

— Section 5.2 —

      ErrorValue       =  error-code
                               *(SEMI error-params)
…
   The ErrorValue contains a 3-digit error code indicating what was
   wrong with the alert in the request.  This error code has a
   corresponding quoted error text string that is human readable.  The
   text string is OPTIONAL, but RECOMMENDED for human readability,
…
   Similar to how RFC
   3261 specifies, there MUST NOT be more than one string per error
   code.

Two things about this:

1. The ABNF makes the text string optional only by allowing zero or more of
them (so zero is allowed).

2. The ABNF allows multiple text strings, but the text says that there MUST NOT
be more than one.

So, shouldn’t the ABNF be this (and if not, why not)?:

NEW
      ErrorValue       =  error-code [SEMI error-params]
END

(Also, and not part of the DISCUSS, “Similar to how RFC 3261 specifies,” is not
good English; maybe, “Similar to the specification in RFC 3261,” or “As
similarly specified in RFC 3261,”.)

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

Some 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).

---

From: Adam Roach <[email-masked]>
Date: Sun, 23 Feb 2020 16:42:51 -0600

> them (so zero is allowed).

This is true. Is this a problem? A production like [*(SEMI 
error-params)] seems redundant.

>        ErrorValue       =  error-code [SEMI error-params]

The production is like it is in the current document because 
"error-params" is not _just_ the error code text. It is defined as 
"error-code-text / generic-param", which is a common way to define SIP 
header fields so that future extensions fit the ABNF in a 
backwards-compatible way (by matching "generic-param").

If, for some reason, you wanted the ABNF to explicitly reflect the prose 
you're citing, it would end up looking like:

Errorvalue = *(SEMI generic-param) [SEMI error-code-text] *(SEMI 
generic-param)

But that's really unnecessarily prolix, and it doesn't even technically 
provide any enforcement, since "error-code-text" also matches 
"generic-param".

What it comes down to is that this is one of the cases, common in SIP, 
where the decision was made to make the ABNF easy-to-read, and to 
provide enforcement of any semantic restrictions as part of the 
normative language rather than attempting to use syntax to do so.

/a

---

From: Barry Leiba <[email-masked]>
Date: Sun, 23 Feb 2020 16:48:02 -0800

> error-params)] seems redundant.

Not in itself; it was part of the overall comment, which is why
point-by-point replies sometimes... miss the point (oof!).

> backwards-compatible way (by matching "generic-param").

Ah, so here's the thing: I missed this line when I read it:

                               / generic-param ; from RFC3261

...and that's the key to why it's written as it is.  Had I noticed it,
I'd never have asked; thanks for pointing it out.

I'm off to clear this point now.

Barry