Non-interactive Emergency Calls
draft-ietf-ecrit-data-only-ea-22

[Ballot comment]
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.

[Ballot comment]
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 , implementers must be aware

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

      that  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
time.  Also, why is the timestamp in the additional information
2010-11-14, almost two years later?

                    32.86726 -97.16054

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 , ,  elements and an
  optional  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/

[Ballot discuss]
(Updated, see the extra review comments)

I have a few a tiny point, but I think they need fixing for clarity:

1)
5.2.  The AlertMsg-Error Header Field

      error-code      = 1*3DIGIT

The text below makes it clear that the error-code is 3 digits:

  The ErrorValue contains a 3-digit error code indicating what was
  wrong with the alert in the request.

What you have above allows for 1, 2 or 3 digits. I think you meant:

      error-code      = 3DIGIT

2) As per Francesca's review: "/=" is illegal in ABNF, it should be "=/"

[Ballot comment]
I initially thought that error-codes are from the same namespace as SIP Status Codes. I think you should explicitly say that they are not.

The first mention of HTTPS needs a normative reference.

In Section 10.1:

  Encoding considerations:  Uses XML, which can employ 8-bit
      characters, depending on the character encoding used.  See
      [RFC7303], Section 3.2.

This field of the form should say one of "7bit", "8bit", "binary" or "framed". I think in your case it is "binary", because UTF-16 charsets are not prohibited in your document.


**********************************************************************
* Note, that I am conducting an experiment when people aspiring to be*
* Area Directors get exposed to AD work ("AD shadowing experiment"). *
* As a part of this experiment they get to review documents on IESG  *
* telechats according to IESG Discuss criteria document and their    *
* comments get relayed pretty much verbatim to relevant editors/WGs. *
* As an AD I retain responsibility in defending their position when  *
* I agree with it.                                                  *
* Recipients of these reviews are encouraged to reply to me directly *
* about perceived successes or failures of this experiment.          *
**********************************************************************

The following comments were provided by Francesca Palombini .
Comments from me are marked with [[Alexey:]].

Francesca would have balloted *DISCUSS* on this document. She wrote:

* Shepherd did not indicate any ABNF verification was done, I took some time to check and:
- message-header  /= AlertMsg-Error I am aware of =/ rule but /=? Don't think that is a valid ABNF op.

[[Alexey:]] well spotted.

- Is error code 1 to 3 digits or 3 digits?

[[Alexey:]] This is the same issue as was reported by me.

- "there MUST NOT be more than one string per error
  code." but ABNF specifies there can be 0 or more error-params which itself contain 1 error code text...

[[Alexey:]] While this can be fixed in ABNF, it is quite common in RFCs to specify such restrictions in prose. So I don't think this issue is problematic.

*  Maybe not worth a discuss? But "AlertMsg-Error: 100 ; code="Cannot Process the Alert Payload"" and following: these are error-code values not AlertMsg-Error (as defined in the ABNF) values, I suggest changing the name so that is clear (e.g. AlertMsg-Error-code: 100 ...)

* Security considerations need to discuss Call-Info header field usage, as that is used, see 20.9 of RFC3261. I do not think the security considerations are enough.

COMMENTS:

* Reference to SIP (RFC3261) is missing first time it appears in the text.
* "This scenario
  corresponds to the classic emergency services use case and the
  description in [RFC6881] is applicable." - I don’t find this sentence very clear. What description in RFC6881? Just needs rephrasing probably.
* I'd like either a note in terminology or a pointer to where Service URN is described the first time it appears.
* I would have liked more info about the "author vs originator" terminology of section 4.2
* "then the  element MUST NOT contain
        the SIP URI of the user agent." MUST it contain author though? That is not specified.
* "the
      element is optional" Should it be OPTIONAL?
* "If the CAP message already contains an  element" seems to imply the CAP message has been constructed elsewhere. Being more explicit about where this CAP message is expected to be formed would make things clearer.
* "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." it is unclear to me what that means of a request not to be "satisfactory". I think it needs to be better specified what can be wrong.
* "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." like what other information? Again unclear imo.
* "; (message-header from 3261)" - missing ref
* Why in Fig3 is the sensor saying that it accepts these? Accept: application/pidf+xml,application/EmergencyCallData.cap+xml
* thanks for checking XML
*"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
  vulnerability is created. " this mechanism needs to be specified in the document, while it is only hinted in the sec cons. If it is not in scope of this doc, that should be highlighted.
* It's media type not MIME type ;) (see https://trac.ietf.org/trac/app/wiki/TypicalAppsAreaIssues#MediaTypes)

[Ballot comment]
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.

[Ballot comment]
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/ ?

[Ballot comment]
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.

[Ballot discuss]
This is a tiny point, but I think it needs fixing for clarity:

5.2.  The AlertMsg-Error Header Field

      error-code      = 1*3DIGIT

The text below makes it clear that the error-code is 3 digits:

  The ErrorValue contains a 3-digit error code indicating what was
  wrong with the alert in the request.

What you have above allows for 1, 2 or 3 digits. I think you meant:

      error-code      = 3DIGIT

[Ballot comment]
I initially thought that error-codes are from the same namespace as SIP Status Codes. I think you should explicitly say that they are not.

The first mention of HTTPS needs a normative reference.

In Section 10.1:

  Encoding considerations:  Uses XML, which can employ 8-bit
      characters, depending on the character encoding used.  See
      [RFC7303], Section 3.2.

This field of the form should say one of "7bit", "8bit", "binary" or "framed". I think in your case it is "binary", because UTF-16 charsets are not prohibited in your document.

[Ballot discuss]
I support Roman's Discuss (and comment) and will expound on his first
point some more.

The use of URIs to refer to remote content, potentially hosted on a
third party, has numerous security considerations, some better known
than others.  We need to reference the security considerations of RFC
3986 to get some coverage of these, such as the "reliability and
consistency" point.

One of the more subtle security considerations of using a URI to a
remote resource as part of a request in cases such as this, is that the
binding between the identity of the entity referring to the remote URI
and the identity of the site providing the corresponding resource (i.e.,
the authority compoent of the URI) is not always clear.  Although RFC
7852 requires TLS mutual authentication and HTTPS transport for
information provided by reference, it makes no statement requiring the
TLS server certificate to correspond to the SIP initiator, or any other
indication of authorization that the indicated resource makes sense as
part of the indicated request.

I also have two other Discuss-level points:

We discuss the use of timestamps in protocol elements for detecting
replay; this requires that all participants have (secure and) accurate
time.  We need to document this dependency on accurate time, and
optionally point out that common internet time protocols such as NTP are
not particularly secure at present.

I'm also not sure where there's existing treatment of using SIP MESSAGEs
as a DoS attack vector; that seems particularly pronounced in the
emergency-services case since emergency messages may receive
preferential treatment from the network.

[Ballot comment]
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 , implementers must be aware

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

      that  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
time.  Also, why is the timestamp in the additional information
2010-11-14, almost two years later?

                    32.86726 -97.16054

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 , ,  elements and an
  optional  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/

[Ballot discuss]
Section 9.  Since CAPs can be included by reference (via URI) and the senders may be unknown to the ESRP/PSAP, please include language on the security considerations for untrusted URIs per Section 7 of RFC3986

Section 9.  Per “To provide protection of the entire SIP message exchange between neighboring SIP entities, the usage of TLS is REQUIRED.”, can you please provide guidance on how to use TLS.

[Ballot comment]
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.

[Ballot comment]
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?

[Ballot comment]
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 alternative 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?

[Ballot 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  combination.  Note that the
      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).

[Ballot 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,”.)

[Ballot 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  combination.  Note that the
      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).

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-ecrit-data-only-ea-18. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are six actions which we must complete.

First, in the application section of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

a new Media Type is to be registered as follows:

Name: cap+xml
Reference: [ RFC-to-be ]
Template: [ TBD-at-Registration ]

Second, in the Emergency Call Data Types registry on the Emergency Call Additional Data registry page located at:

https://www.iana.org/assignments/emergency-call-additional-data/

a new registration will be made as follows:

Token: cap
Data About: The Call
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, in the Response Codes registry on the Session Initiation Protocol (SIP) Parameters registry page located at:

https://www.iana.org/assignments/sip-parameters/

a single, new response code will be registered as follows:

Response Code: [ TBD-at-Registration ]
Description: Bad Alert Message
Reference: [ RFC-to-be ]

IANA notes that the value of 425 is recommended to be used for this new registration.

Fourth, in the Header Fields registry also on the Session Initiation Protocol (SIP) Parameters registry page located at:

https://www.iana.org/assignments/sip-parameters/

a single, new header field will be registered as follows:

Header Name: AlertMsg-Error
Compact:
Reference: [ RFC-to-be ]

Fifth, in the Header Field Parameters and Parameter Values registry also on the Session Initiation Protocol (SIP) Parameters registry page located at:

https://www.iana.org/assignments/sip-parameters/

a single, new registration will be made as follows:

Header Field: AlertMsg-Error
Parameter Name: code
Values: yes
Reference: [ RFC-to-be ]

Sixth, a new registry is to be created called the AlertMsg-Error Codes registry, The new registry will be located on the Session Initiation Protocol (SIP) Parameters registry page located at:

https://www.iana.org/assignments/sip-parameters/

The new registry will be managed via Specification Required as defined in RFC 8126. there are initial registrations in the new registry as follows:

Code Default Reason Phrase Reference
---- --------------------------------------------------- -------------
100 "Cannot Process the Alert Payload" [ RFC-to-be ]
101 "Alert Payload was not present or could not be found" [ RFC-to-be ]
102 "Not enough information to determine
the purpose of the alert" [ RFC-to-be ]
103 "Alert Payload was corrupted" [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-09-02):

From: The IESG
To: IETF-Announce
CC: adam@nostrum.com, allison.mankin@gmail.com, Allison Mankin , ecrit-chairs@ietf.org, draft-ietf-ecrit-data-only-ea@ietf.org, ecrit@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Data-Only Emergency Calls) to Proposed Standard


The IESG has received a request from the Emergency Context Resolution with
Internet Technologies WG (ecrit) to consider the following document: -
'Data-Only Emergency Calls'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-09-02. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  RFC 6443 'Framework for Emergency Calling Using Internet Multimedia'
  describes how devices use the Internet to place emergency calls and
  how Public Safety Answering Points (PSAPs) handle Internet multimedia
  emergency calls natively.  The exchange of multimedia traffic for
  emergency services involves a Session Initiation Protocol (SIP)
  session establishment starting with a SIP INVITE that negotiates
  various parameters for that session.

  In some cases, however, the transmission of application data is all
  that is needed.  Examples of such environments include alerts issued
  by a temperature sensor, burglar alarm, or chemical spill sensor.
  Often these alerts are conveyed as one-shot data transmissions.
  These type of interactions are called 'data-only emergency calls'.
  This document describes a container for the data based on the Common
  Alerting Protocol (CAP) and its transmission using the SIP MESSAGE
  transaction.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ballot/


No IPR declarations have been submitted directly on this I-D.

The AD review has not appeared in the ECRIT mailing list archives in a timely fashion. It is copied below.


This is my AD review of draft-ietf-ecrit-data-only-ea. Thanks for the
work everyone has put into this document. I have a number of issues that
need to be resolved prior to putting this document on an IESG telechat,
but none of them preclude putting the document into IETF last call.
Please address the comments below along with any other IETF last call
comments you may receive.

---------------------------------------------------------------------------

§2:

Please update this section to use the boilerplate from RFC 8174.

---------------------------------------------------------------------------

§3:

>  In Figure 2 a scenario is shown whereby the alert is routed using
>  location information and a Service URN.  An emergency services
>  routing proxy (ESRP) may use LoST

Please informatively cite RFC 5222 here.

---------------------------------------------------------------------------

§3:

>  A PSAP, for example, is likely to
>  receive and accept alerts from entities it cannot authorize.

Nit: s/authorize/authenticate/

---------------------------------------------------------------------------


§3:

>          | MESSAGE with CAP  |                              |
>          | (including Service URN,                          |
>          | such as urn:service:sos)                        |
>          |-------------------|                              |

Nit: add an arrow head to this line.

---------------------------------------------------------------------------

§4.1:

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

Nit: "alternatively"

---------------------------------------------------------------------------

§4.1:

>  If the SIP server does not support the functionality required to
>  fulfill the request then a 501 Not Implemented MUST be returned as
>  specified in [RFC3261].
...
>  The 415 Unsupported Media Type error MUST be returned as specified in
>  [RFC3261] if the SIP server is refusing to service the request

Please avoid reiterating normative behavior using normative language.
These can be rephrased as "...will be returned as specified..." and "...error
will be returned..."

---------------------------------------------------------------------------

§4.2:

>    Originator is a non-SIP entity, Author indication irrelevant:
>    When the alert was created by a non-SIP based entity and the

Nit: the indentation of this paragraph doesn't match that of the surrounding
paragraphs.

---------------------------------------------------------------------------

§5.2:

>  That said,
>  the strings are complete enough for rendering to the user, if so
>  desired.

This raises the question of localization of these strings. If this document is
going to suggest rendering of these strings to users, then they minimally need
some kind of language code added, and ideally need some treatment of language
negotiation (using, e.g., the "Accept-Language" header field).

It's probably easier to simply remove this suggestion at this point, and treat
the corresponding strings in the same way as reason phrases in normal SIP
responses are treated.

---------------------------------------------------------------------------

§5.2:

>  For
>  example, a UA includes an alert in a MESSAGE to a PSAP.  The PSAP can
>  accept this MESSAGE, thus creating a dialog, even though its UA
>  determined that the alert message contained in the MESSAGE was bad.

This example doesn't make sense: MESSAGE does not create a dialog. I think this
paragraph intended to say "INVITE"?

---------------------------------------------------------------------------

§5.2:

>  This document defines an initial list of AlertMsg-Error values for
>  any SIP response, including provisional responses

I think this probably needs some treatment of the unreliability of provisional
responses. One approach would be language requiring that AlertMsg-Error
values sent in provisional responses must be sent using the mechanism
defined in RFC 3262; or, if that mechanism is not negotiated, it must be
repeated in the final response to the transaction.

---------------------------------------------------------------------------

§8:

>    Call-ID: asd88asd77a@2001:DB8:0:0FF

Thanks for using an IPv6 address here! :)

This address has a number of nit-level issues:
  - Letters should be lowercase
  - Leading zeros are omitted from each group
  - There must be 8 colon-separated values unless the "::" elision is used

The following is valid:

      Call-ID: asd88asd77a@2001:db8::ff

---------------------------------------------------------------------------

§8:

>    --boundary1
>
>    Content-Type: application/EmergencyCallData.cap+xml
>    Content-ID:
>    Content-Disposition: by-reference;handling=optional
>   

Please remove the blank line after "--boundary1"

Please add a blank line between the "Content-Disposition" line and the XML.

Please adjust the example so that the XML is indented the same amount
as the rest of the example (e.g., this first line is outdented by one
character as compared to the SIP and MIME headers)

>    --boundary1
>
>    Content-Type: application/pidf+xml
>    Content-ID:
>    Content-Disposition: by-reference;handling=optional
>   

Same comments as above regarding blank lines.

---------------------------------------------------------------------------


§8:

>                    32.86726 -97.16054

As a completely random aside, I'm amused at how close to my house this is.

---------------------------------------------------------------------------

§9:

>  With the scenario shown in Figure 1 it is very likely
>  that only authorized sensor input will be processed.

s/authorized/authenticated/

---------------------------------------------------------------------------

§9:

>  1.  SIP itself provides security mechanisms that allow the
>      verification of the originator's identity.  These mechanisms can
>      be re-used, 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.

The second sentence is kind of non-sequitur (the part after the comma
doesn't follow from the part before it). Suggested revision:

  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 re-used.

---------------------------------------------------------------------------

§9:

>  Additionally, it is RECOMMENDED to make
>  use of SIP security mechanisms, such as SIP Identity [RFC8224], to
>  tie the CAP message to the SIP message.

While RFC 4474 would have provided this kind of binding (as it included the
message body), RFC 8224 no longer does. I think this means to point to
PASSporT [RFC8225].

---------------------------------------------------------------------------

§10.1:

>  Author/Change controller:  IETF ECRIT working group

Please set the change controller to the IESG.

---------------------------------------------------------------------------

§10.4:

>  2.  In the portion titled "Header Field Parameters and Parameter
>      Values", add
>
>                                              Predefined
>    Header Field        Parameter Name      Values      Reference
>    -----------------  -------------------  ----------  ---------
>    AlertMsg-Error      code                yes        [this doc]


RFC 3969 defines "Predefined Values" as:

  Some SIP and SIPS URI parameters only accept a set of predefined
  parameter values.  For example, a parameter indicating the transport
  protocol in use may only accept the predefined tokens TCP, UDP, and
  SCTP as valid values.

So, while this document does define some suggested values for "code",
recipients are expected to accept values other than these suggestions.
By the RFC 3969 definition, "Predefined Values" should be "no".

The document is requested to be a Proposed Standard. 

Technical Summary

  RFC 6443 'Framework for Emergency Calling Using Internet Multimedia'
  describes how devices use the Internet to place emergency calls and
  how Public Safety Answering Points (PSAPs) handle Internet multimedia
  emergency calls natively.  The exchange of multimedia traffic for
  emergency services involves a Session Initiation Protocol (SIP)
  session establishment starting with a SIP INVITE that negotiates
  various parameters for that session.

  In some cases, however, the transmission of application data is all
  that is needed.  Examples of such environments include alerts issued
  by a temperature sensor, burglar alarm, or chemical spill sensor.
  Often these alerts are conveyed as one-shot data transmissions.
  These type of interactions are called 'data-only emergency calls'.
  This document describes a container for the data based on the Common
  Alerting Protocol (CAP) and its transmission using the SIP MESSAGE
  transaction.

Working Group Summary

This document did not have controversy in the WG.  Its revisions were in response to a number of very detailed
reviews in 2013-2015, and then in order to track with RFC 7252 'Additional Data Related to an Emergency Call.'

Document Quality

There were many detailed reviews throughout the lifetime of the draft.  Another quality indicator is
that the editors worked with the NENA Long Term Direction Working Group, and updated other emergency
communications groups throughout the development time in ECRIT.

The Media Type expert review request for application/EmergencyCallData.cap+xml was posted on March 23, 2018.

The Document Shepherd has reviewed the mailing list discussions, expert reviewing, and normative references.
There are no concerns about the degree of review, special review needs, or other concerns.   
Because of the very active reviewing early on, the Shepherd views this document as having solid WG consensus. 

The document had its required formal review of the media type (see above)

There is a normative reference that will need to be added to the Downref Registry -
the document depends on the OASIS Common Alerting Protocol v.1.2 specification
(http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html)

No existing RFCs are updated or obsoleted by this document. 

A new block is to be added to the IANA Emergency Call Data Types Registry. 
The criteria for this (RFC 7852) are Specification Required with explicit
Expert Review - the IANA Expert Reviewer is Brian Rosen, who is also the
pen-holding editor of this document.

A SIP Response Code is requested - the criterion for this (RFC 3261) is RFC Required.

A SIP Header Type is requested - the policy for this is Standards Action - the Expert Reviewer
is Adam Roach, who is also the Responsible AD.

A new SIP Registry, called AlertMsg Error Codes, is to be created, with a Specification Required policy.

There is one XML example, and it was validated through the Oxygen XML Editor.

Personnel

The Document Shepherd is Allison Mankin, and the Responsible Area Director is Adam Roach.

The document is requested to be a Proposed Standard. 

Technical Summary

  RFC 6443 'Framework for Emergency Calling Using Internet Multimedia'
  describes how devices use the Internet to place emergency calls and
  how Public Safety Answering Points (PSAPs) handle Internet multimedia
  emergency calls natively.  The exchange of multimedia traffic for
  emergency services involves a Session Initiation Protocol (SIP)
  session establishment starting with a SIP INVITE that negotiates
  various parameters for that session.

  In some cases, however, the transmission of application data is all
  that is needed.  Examples of such environments include alerts issued
  by a temperature sensor, burglar alarm, or chemical spill sensor.
  Often these alerts are conveyed as one-shot data transmissions.
  These type of interactions are called 'data-only emergency calls'.
  This document describes a container for the data based on the Common
  Alerting Protocol (CAP) and its transmission using the SIP MESSAGE
  transaction.

Working Group Summary

This document did not have controversy in the WG.  Its revisions were in response to a number of very detailed
reviews in 2013-2015, and then in order to track with RFC 7252 'Additional Data Related to an Emergency Call.'

Document Quality

There were many detailed reviews throughout the lifetime of the draft.  Another quality indicator is
that the editors worked with the NENA Long Term Direction Working Group, and updated other emergency
communications groups throughout the development time in ECRIT.

The Media Type expert review request for application/EmergencyCallData.cap+xml was posted on March 23, 2018.

The Document Shepherd has reviewed the mailing list discussions, expert reviewing, and normative references.
There are no concerns about the degree of review, special review needs, or other concerns.   
Because of the very active reviewing early on, the Shepherd views this document as having solid WG consensus. 

The document had its required formal review of the media type (see above)

There is a normative reference that will need to be added to the Downref Registry -
the document depends on the OASIS Common Alerting Protocol v.1.2 specification
(http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html)

No existing RFCs are updated or obsoleted by this document. 

A new block is to be added to the IANA Emergency Call Data Types Registry. 
The criteria for this (RFC 7852) are Specification Required with explicit
Expert Review - the IANA Expert Reviewer is Brian Rosen, who is also the
pen-holding editor of this document.

A SIP Response Code is requested - the criterion for this (RFC 3261) is RFC Required.

A SIP Header Type is requested - the policy for this is Standards Action - the Expert Reviewer
is Adam Roach, who is also the Responsible AD.

A new SIP Registry, called AlertMsg Error Codes, is to be created, with a Specification Required policy.

There is one XML example, and it was validated through the Oxygen XML Editor.

Personnel

The Document Shepherd is Allison Mankin, and the Responsible Area Director is Adam Roach.