Subject: [Ecrit] AD Review: draft-ietf-ecrit-data-only-ea

From: Adam Roach <[email-masked]>
Date: Fri, 2 Aug 2019 20:24:46 -0500

[re-sending due to some now-resolved issues with the IETF mail servers]

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: <[email-masked]>
>     Content-Disposition: by-reference;handling=optional
>    <?xml version="1.0" encoding="UTF-8"?>

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: <[email-masked]>
>     Content-Disposition: by-reference;handling=optional
>     <?xml version="1.0" encoding="UTF-8"?>

Same comments as above regarding blank lines.

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

§8:

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

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.

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