Non-interactive Emergency Calls
RFC 8876

Note: This ballot was opened for revision 21 and is now closed.

Alvaro Retana No Objection

Benjamin Kaduk (was Discuss) No Objection

Comment (2020-03-10)
Thank you for addressing my Discuss points!

Original (presumed stale) comments preserved below.

Introduction (and Abstract?)

   medical monitors.  These messages may be one-shot alerts to emergency
   authorities and do not require establishment of a session.  These
   type of interactions are called 'non-interactive emergency calls'.

Is this an existing/widespread definition or one new to this document?
It may be worth providing a reference or rewording to clarify that it is
a new definition.

Section 2

   CID is Content InDirection [RFC2392]

The string "InDirection" does not appear in RFC 2392.

Section 4.1

   A CAP message may be sent in the initial message of any SIP
   transaction.  However, this document only addresses sending a CAP
   message in a SIP MESSAGE transaction for a one-shot, non-interactive
   emergency call.  Behavior with other transactions is not defined.

I suggest rephrasing to "A CAP message is sent in the initial message of
a SIP transaction" to avoid potential concerns about inconsistency
between "may be sent" and "not defined".

   the CAP message.  Alternatively, the Call-Info header field may
   contain a Content Indirect url [RFC2392] and the CAP message included

nit: "Indirect" here vs. "InDirection" in Section 2

Section 4.2

      field.  If there is a need to copy the PIDF-LO structure
      referenced by 'geolocation' to <area>, implementers must be aware

When might this occur?  (It seems almost out of scope for this document
based on my limited understanding.)

      that <area> is limited to a circle or polygon, and conversion of
      other shapes will be required.  Points SHOULD be converted to a
      circle with a radius equal to the uncertainty of the point.  Arc-
      bands and ellipses SHOULD be converted to an equivalent polygon.
      3D locations SHOULD be converted to their equivalent 2D forms.

nit: what is an "equivalent" polygon to an ellipse or arc-band?  In a
mathematical sense it might mean "strict equivalence" or a large-n limit
of an n-gon, or perhaps there is a corresponding uncertainty on the
ellipse/arc-band that the polygon must stay within?  Rewording to
"corresponding" might be an easy fix.

Section 5.1

   The 425 response code is a rejection of the request due to its
   included alert content, indicating that it was malformed or not
   satisfactory for the recipient's purpose.

   A SIP intermediary can also reject an alert it receives from a User
   Agent (UA) when it detects that the provided alert is malformed.

(I assume there's an implicit "reject with this code" in here.)

   It is only appropriate to generate a 425 response when the responding
   entity has no other information in the request that is usable by the
   responder.

I'm not sure I'm parsing this sentence correctly.  My best guess is that
it's saying "if there's anything in the request that you can respond to,
don't use 425, even if there's some malformed CAP", but that doesn't
really seem to be what the actual words are saying.  [Section 5.2 seems
to support my guess.]

Section 5.2

      message-header   /= AlertMsg-Error
                              ; (message-header from 3261)

nit: mybe "RFC3261" to match the later comments?

   wrong with the alert in the request.  This error code has a

pedantic nit: the ABNF has 1-to-3-digit

   standardized -- meaning an operator can change the strings -- but
   MUST NOT change the meaning of the error code.  Similar to how RFC
   3261 specifies, there MUST NOT be more than one string per error
   code.

RFC 3261 is ... pretty long.  Maybe throw us a bone with a section
reference?  Also, I assume this "MUST NOT be more than one" is within a
single AlertMsg-Error construction, since a truly global interpretation
would mean that (since this document assigns strings) there cannot
actually be changes made to the strings by an operator, which we just
said is possible.

   This document defines an initial list of AlertMsg-Error values for
   any SIP response, including provisional responses (other than 100
   Trying) and the new 425 response.  There MUST be no more than one
   AlertMsg-Error code in a SIP response.  AlertMsg-Error values sent in

Is this redundant with the "MUST NOT" I was asking about above?

   Additionally, if an entity cannot or chooses not to process the alert
   message from a SIP request, a 500 (Server Internal Error) SHOULD be
   used with or without a configurable Retry-After header field.

I don't think I understand when it's recommended to use 500 vs 425 (and
vice versa).

Section 7

It's probably worth mentioning RFC 3428's note about:

%  The size of MESSAGE requests outside of a media session MUST NOT
%  exceed 1300 bytes, unless the UAC has positive knowledge that the
%  message will not traverse a congestion-unsafe link at any hop, or
%  that the message size is at least 200 bytes less than the lowest MTU
%  value found en route to the UAS

since that seems to still apply here.

Section 8

I'd consider using a more recent date than 2008-11-19 for the example
<sent> time.  Also, why is the timestamp in the additional information
2010-11-14, almost two years later?

                     <gml:pos>32.86726 -97.16054</gml:pos>

Is that ... someone's house?  Maybe some different coordinates would be
more appropriate.

Figure 3 has "Content-Disposition: by-reference;handling=optional" but
Figure 4 does not; is that significant?

Section 9

   In any case, for alerts initiated by sensors, the identity could play
   an important role in deciding whether to accept or ignore an incoming
   alert message.  With the scenario shown in Figure 1 it is very likely
   that only authenticated sensor input will be processed.  For this
   reason, it needs to be possible to refuse to accept alert messages
   from an unknown origin.  Two types of information elements can be
   used for this purpose:

   1.  SIP itself provides security mechanisms that allow the
       verification of the originator's identity, such as P-Asserted-
       Identity [RFC3325] or SIP Identity [RFC8224].  The latter
       provides a cryptographic assurance while the former relies on a
       chain of trust model.  These mechanisms can be reused.

   2.  CAP provides additional security mechanisms and the ability to
       carry further information about the sender's identity.
       Section 3.3.4.1 of [cap] specifies the signing algorithms of CAP
       documents.

I'd consider adding a note that "the specific policy and mechanisms used
in a given deployment are out of scope for this document", since the
actual requirements in practice are so broad that we cannot really make
detailed recommendations here.

   In addition to the desire to perform identity-based access control,
   the classic communication security threats need to be considered,
   including integrity protection to prevent forgery or replay of alert
   messages in transit.  To deal with replay of alerts, a CAP document
   contains the mandatory <identifier>, <sender>, <sent> elements and an
   optional <expire> element.  Together, these elements make the CAP
   document unique for a specific sender and provide time restrictions.
   An entity that has already received a CAP message within the
   indicated timeframe is able to detect a replayed message and, if the
   content of that message is unchanged, then no additional security

Is *able* to detect, sure.  But is it recommended to do so?  Required?

   vulnerability is created.  Additionally, it is RECOMMENDED to make
   use of SIP security mechanisms, such as the SIP Identity PASSporT
   [RFC8225], to tie the CAP message to the SIP message.  To provide

Not required?  Please describe the risks of not doing so (whether
directly or by reference).

   protection of the entire SIP message exchange between neighboring SIP
   entities, the usage of TLS is REQUIRED.

Just to check: this is a 100% always, for everyone, "REQUIRED", not just
in the subset of cases where protection of the entire exchange is
desired?

   Note that none of the security mechanism in this document protect
   against a compromised sensor sending crafted alerts.  Privacy
   provided for any emergency calls, including non-interactive messages,
   is subject to local regulations.

I suggest using "confidentiality protection" rather than "privacy"
(unless it's a term of art in this field), to avoid confusion with...
Privacy considerations for alerts (e.g., generated by sensors) that
should be discussed.  RFC 7852 has some extensive privacy considerations
that can be referenced to do the bulk of the work here.

I'd also consider reiterating the opportunistic nature of cryptographic
protection on emergency messages, as discussed in 6443 (since insecure
emergency messaging is preferred to no emergency messaging), but this is
not strictly speaking required.

Section 12.2

RFC 8225, as a RECOMMENDED feature, is more properly listed as a
normative reference, per
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/

Martin Vigoureux No Objection

Comment (2020-03-05 for -21)
Hi,

A very minor question:
I have noticed 4 occurrences of "SIP message" (lower case). Just checking if this is intentional since there are occurrences in upper case.

Roman Danyliw (was Discuss) No Objection

Comment (2020-03-10)
Thanks for addressing my DISCUSS items.

--[ old comments
Section 1.  Per “These messages may be one-shot alerts to emergency authorities …”, aren’t these alerts as scoped for the purposes of this document _always_ “one-shot alerts”?

Section 4.2.  In the definition of ‘area’, please note that the various conversions (e.g., arc-bands to equivalent polygons) are out of scope of this document.

Warren Kumari No Objection

Comment (2020-03-03 for -21)
I support Roman, Benjamin and Alexey's DISCUSSes, but as they are already holding them, I see no need to add to them.

I agree that the a shorter abstract would be good - an abstract should allow me to quickly determine if the document is relevant to me -- I like the text in the abstract, but think that much of it could instead be in the introduction.

Éric Vyncke No Objection

Comment (2020-03-04 for -21)
Thank you for the work put into this document. 

Please address all the NITs found in the IoT directorate review by Gonzalo Salgueiro:
https://datatracker.ietf.org/doc/review-ietf-ecrit-data-only-ea-21-iotdir-telechat-salgueiro-2020-03-02/
Thank you again Gonzalo !

And another NIT below.

I hope that this helps to improve the document,

Regards,

-éric

-- Section 4.2 --
About "incidents", s/may not be present/MAY not be present/ ?

(Adam Roach; former steering group member) Yes

Yes ( for -21)
No email
send info

(Alissa Cooper; former steering group member) Yes

Yes ( for -21)

(Alexey Melnikov; former steering group member) (was Discuss) No Objection

No Objection (2020-03-10)
Thank you for addressing my DISCUSS points and comments.

(Barry Leiba; former steering group member) (was Discuss) No Objection

No Objection (2020-02-23 for -21)
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).

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -21)

(Magnus Westerlund; former steering group member) No Objection

No Objection ( for -21)

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2020-02-28 for -21)
One question: Should non-inactive SIP MESSAGEs be rated-limited somehow or it that already specified in the SIP spec (sorry don't know that by heart ;-)? If so a pointer would probably be good. Or maybe another thing to add to section 7 (or a subsection or an own section) or alternatively to the security considerations section I guess.

One small comment/nit:
Sec 5.2:
"AlertMsg-Error values sent in
   provisional responses must be sent using the mechanism defined in
   [RFC3262]; or, if that mechanism is not negotiated, it must be
   repeated in the final response to the transaction."
Maybe two times MUST?

(Suresh Krishnan; former steering group member) No Objection

No Objection ( for -21)