[Ecrit] AD Review: draft-ietf-ecrit-data-only-ea
Adam Roach <adam@nostrum.com> Sat, 03 August 2019 01:24 UTC
Return-Path: <adam@nostrum.com>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9410C120018; Fri, 2 Aug 2019 18:24:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.98
X-Spam-Level:
X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lI-6L1ONfFZ; Fri, 2 Aug 2019 18:24:53 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3E7D12001E; Fri, 2 Aug 2019 18:24:53 -0700 (PDT)
Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x731OpLP031850 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 2 Aug 2019 20:24:52 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1564795493; bh=8KKwJv0mvbpuEVZ7jesvG05qWeBfIqDoMNGs8cC7BlI=; h=From:Subject:To:Date; b=RGG9K7FlN2lqdXTIIu8f+N4UPBjBFOuDEfNBeXdszr1kI2SCur6wLPHMirhOPBizG WB/IF21235fGiJ0d1HIOnBuaiGDzdvQb5+eMeh2NsYveDeWaNBmmWFn7IU8cO5gd7g kOXPt8dc1JugKcEx67OmpEQAHhfS3BHHMCHSDrcA=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at
From: Adam Roach <adam@nostrum.com>
To: draft-ietf-ecrit-data-only-ea.all@ietf.org, ecrit@ietf.org
Message-ID: <b7ec90ba-78d6-af5d-c4f2-98cfad7b4f33@nostrum.com>
Date: Fri, 02 Aug 2019 20:24:46 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/pXL3umsyKqwDiVPgV4tIySMkcJo>
Subject: [Ecrit] AD Review: draft-ietf-ecrit-data-only-ea
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Aug 2019 01:24:56 -0000
[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: <abcdef2@example.com> > 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: <abcdef2@example.com> > 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".