From nobody Fri Aug 2 17:57:35 2019 Return-Path: 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 90E8912001E; Fri, 2 Aug 2019 17:57:32 -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 z4tP0igEcCpR; Fri, 2 Aug 2019 17:57:30 -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 3BDA4120018; Fri, 2 Aug 2019 17:57:27 -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 x7306sfN019221 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 2 Aug 2019 19:06:55 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1564790816; bh=zvifAw99RzqdQDqfmsc9i2H3U1OHlQyC+YLjyhijvpk=; h=To:From:Subject:Date; b=Bx9Oe7hfcxKnGG7svMbfBpOaykfAahWGYl/10KMsVHa7q+YaAC7FpBw83RLCVZBW7 WwzEY0ysqPw3+itHbOdqZZrwWyqj+DkwLsf+2/4Z4dElhn2/gZgQ3guZAc4i/9R6Ta UheRJTRBr1Jfgz0UQNkTm3cvGDblvdFk6s/9kex0= 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 To: draft-ietf-ecrit-data-only-ea.all@ietf.org, ecrit@ietf.org From: Adam Roach Message-ID: <982b623b-2894-b16d-0437-0d7e64658e80@nostrum.com> Date: Fri, 2 Aug 2019 19:06:49 -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-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2019 00:57:33 -0000 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. 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". From nobody Fri Aug 2 17:57:42 2019 Return-Path: X-Original-To: expand-draft-ietf-ecrit-data-only-ea.all@virtual.ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id F2305120018; Fri, 2 Aug 2019 17:57:32 -0700 (PDT) X-Original-To: xfilter-draft-ietf-ecrit-data-only-ea.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-ecrit-data-only-ea.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E8912001E; Fri, 2 Aug 2019 17:57:32 -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 z4tP0igEcCpR; Fri, 2 Aug 2019 17:57:30 -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 3BDA4120018; Fri, 2 Aug 2019 17:57:27 -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 x7306sfN019221 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 2 Aug 2019 19:06:55 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1564790816; bh=zvifAw99RzqdQDqfmsc9i2H3U1OHlQyC+YLjyhijvpk=; h=To:From:Subject:Date; b=Bx9Oe7hfcxKnGG7svMbfBpOaykfAahWGYl/10KMsVHa7q+YaAC7FpBw83RLCVZBW7 WwzEY0ysqPw3+itHbOdqZZrwWyqj+DkwLsf+2/4Z4dElhn2/gZgQ3guZAc4i/9R6Ta UheRJTRBr1Jfgz0UQNkTm3cvGDblvdFk6s/9kex0= 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 To: draft-ietf-ecrit-data-only-ea.all@ietf.org, ecrit@ietf.org From: Adam Roach Message-ID: <982b623b-2894-b16d-0437-0d7e64658e80@nostrum.com> Date: Fri, 2 Aug 2019 19:06:49 -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-Transfer-Encoding: 8bit Content-Language: en-US Resent-From: Resent-To: br@brianrosen.net, hgs+ecrit@cs.columbia.edu, hannes.tschofenig@arm.com, rg+ietf@coretechnologyconsulting.com, allison.mankin@gmail.com, roger.marshall@comtechtel.com, barryleiba@computer.org, adam@nostrum.com, aamelnikov@fastmail.fm, Allison Mankin , draft-ietf-ecrit-data-only-ea@ietf.org, ecrit@ietf.org Resent-Message-Id: <20190803005732.F2305120018@ietfa.amsl.com> Resent-Date: Fri, 2 Aug 2019 17:57:32 -0700 (PDT) Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2019 00:57:33 -0000 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. 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". From nobody Fri Aug 2 18:24:56 2019 Return-Path: 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 To: draft-ietf-ecrit-data-only-ea.all@ietf.org, ecrit@ietf.org Message-ID: Date: Fri, 2 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: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: >     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. 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". From nobody Fri Aug 2 18:25:05 2019 Return-Path: X-Original-To: expand-draft-ietf-ecrit-data-only-ea.all@virtual.ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id E786B12001E; Fri, 2 Aug 2019 18:24:55 -0700 (PDT) X-Original-To: xfilter-draft-ietf-ecrit-data-only-ea.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-ecrit-data-only-ea.all@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 To: draft-ietf-ecrit-data-only-ea.all@ietf.org, ecrit@ietf.org Message-ID: Date: Fri, 2 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 Resent-From: Resent-To: br@brianrosen.net, hgs+ecrit@cs.columbia.edu, hannes.tschofenig@arm.com, rg+ietf@coretechnologyconsulting.com, allison.mankin@gmail.com, roger.marshall@comtechtel.com, barryleiba@computer.org, adam@nostrum.com, aamelnikov@fastmail.fm, Allison Mankin , draft-ietf-ecrit-data-only-ea@ietf.org, ecrit@ietf.org Resent-Message-Id: <20190803012455.E786B12001E@ietfa.amsl.com> Resent-Date: Fri, 2 Aug 2019 18:24:55 -0700 (PDT) Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: >     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. 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". From nobody Mon Aug 19 06:47:44 2019 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6326D120045; Mon, 19 Aug 2019 06:47:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Sender: 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 Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156622246329.19940.11808026095630842895.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2019 06:47:43 -0700 Archived-At: Subject: [Ecrit] Last Call: (Data-Only Emergency Calls) to Proposed Standard X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 13:47:43 -0000 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. From nobody Wed Aug 21 00:58:47 2019 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C7F1200FD; Wed, 21 Aug 2019 00:58:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder_via_Datatracker?= To: Cc: draft-ietf-ecrit-data-only-ea.all@ietf.org, ietf@ietf.org, ecrit@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?b?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= Message-ID: <156637431059.25793.14714439713955747630@ietfa.amsl.com> Date: Wed, 21 Aug 2019 00:58:30 -0700 Archived-At: Subject: [Ecrit] Opsdir last call review of draft-ietf-ecrit-data-only-ea-18 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 07:58:31 -0000 Reviewer: Jürgen Schönwälder Review result: Has Issues I assume all my comments are easy to resolve. Some are purley editorial, others may require minor content changes, hence I ticked 'has issues'. The comments are in document order and not ordered by 'seriousness'. - The acronym 'LoST' pops up in section 3 without any explanation what it expands to or what it means. This appears to be to only occurrence of 'LoST' in the document, which makes me feel lost. - It seems that in 4.2 there are three cases distinguished under the 'sender:' list item but the indentation somewhat confuses this. Perhaps the typesetting can be improved, e.g. sender: ... - Originator is a SIP entity, Author indication irrelevant: ... - Originator is a non-SIP entity, Author indication irrelevant: ... - Author indication relevant: ... Right now the last ends up on the level of 'sender:' and the text indentation of the first two is different. - What is a 'PIDF-LO' structure? References missing. - Section 4.3 says that a data-only emergency call is sent using a SIP MESSAGE transaction. Earlier text says that "this document only addresses sending a CAP message in a SIP INVITE that initiates an emergency call, or in a SIP MESSAGE transaction for a one-shot, data-only emergency call." It seems there is no further text detailing the SIP INVITE case nor is it clear how one decides between the two options. The examples also focus on the MESSAGE case and the security considerations also discuss MESSAGE and CAP (and not INVITE). - Do the authors use 'human understandable' and 'human readable' as synonyms? If so, it seems 'human readable' is the more common phrase with which we describe texts in protocol messages. - Section 7 warns about sending 'large quantities of data'. Is it possible to be a bit more precise what 'large' means? Is 1k large? Is 10k large? Is 1m large? There is also the phrase 'very large', is that the same as 'large' here? I am not looking for a precise number but rather an indication up to which magnitude sending data inline may be safe. From nobody Wed Aug 21 00:58:54 2019 Return-Path: X-Original-To: expand-draft-ietf-ecrit-data-only-ea.all@virtual.ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 5081A120881; Wed, 21 Aug 2019 00:58:31 -0700 (PDT) X-Original-To: draft-ietf-ecrit-data-only-ea.all@ietf.org Delivered-To: xfilter-draft-ietf-ecrit-data-only-ea.all@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C7F1200FD; Wed, 21 Aug 2019 00:58:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder_via_Datatracker?= To: Cc: draft-ietf-ecrit-data-only-ea.all@ietf.org, ietf@ietf.org, ecrit@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?b?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= Message-ID: <156637431059.25793.14714439713955747630@ietfa.amsl.com> Date: Wed, 21 Aug 2019 00:58:30 -0700 Resent-From: Resent-To: br@brianrosen.net, hgs+ecrit@cs.columbia.edu, hannes.tschofenig@arm.com, rg+ietf@coretechnologyconsulting.com, allison.mankin@gmail.com, roger.marshall@comtechtel.com, barryleiba@computer.org, adam@nostrum.com, aamelnikov@fastmail.fm, Allison Mankin , draft-ietf-ecrit-data-only-ea@ietf.org, ecrit@ietf.org Resent-Message-Id: <20190821075831.5081A120881@ietfa.amsl.com> Resent-Date: Wed, 21 Aug 2019 00:58:31 -0700 (PDT) Archived-At: Subject: [Ecrit] Opsdir last call review of draft-ietf-ecrit-data-only-ea-18 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 07:58:31 -0000 Reviewer: Jürgen Schönwälder Review result: Has Issues I assume all my comments are easy to resolve. Some are purley editorial, others may require minor content changes, hence I ticked 'has issues'. The comments are in document order and not ordered by 'seriousness'. - The acronym 'LoST' pops up in section 3 without any explanation what it expands to or what it means. This appears to be to only occurrence of 'LoST' in the document, which makes me feel lost. - It seems that in 4.2 there are three cases distinguished under the 'sender:' list item but the indentation somewhat confuses this. Perhaps the typesetting can be improved, e.g. sender: ... - Originator is a SIP entity, Author indication irrelevant: ... - Originator is a non-SIP entity, Author indication irrelevant: ... - Author indication relevant: ... Right now the last ends up on the level of 'sender:' and the text indentation of the first two is different. - What is a 'PIDF-LO' structure? References missing. - Section 4.3 says that a data-only emergency call is sent using a SIP MESSAGE transaction. Earlier text says that "this document only addresses sending a CAP message in a SIP INVITE that initiates an emergency call, or in a SIP MESSAGE transaction for a one-shot, data-only emergency call." It seems there is no further text detailing the SIP INVITE case nor is it clear how one decides between the two options. The examples also focus on the MESSAGE case and the security considerations also discuss MESSAGE and CAP (and not INVITE). - Do the authors use 'human understandable' and 'human readable' as synonyms? If so, it seems 'human readable' is the more common phrase with which we describe texts in protocol messages. - Section 7 warns about sending 'large quantities of data'. Is it possible to be a bit more precise what 'large' means? Is 1k large? Is 10k large? Is 1m large? There is also the phrase 'very large', is that the same as 'large' here? I am not looking for a precise number but rather an indication up to which magnitude sending data inline may be safe. From nobody Sat Aug 24 12:53:33 2019 Return-Path: X-Original-To: expand-draft-ietf-ecrit-data-only-ea.all@virtual.ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 23205120020; Sat, 24 Aug 2019 12:53:15 -0700 (PDT) X-Original-To: xfilter-draft-ietf-ecrit-data-only-ea.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-ecrit-data-only-ea.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8661D12006E; Sat, 24 Aug 2019 12:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 TQcwreJL7d15; Sat, 24 Aug 2019 12:53:12 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-oln040092004034.outbound.protection.outlook.com [40.92.4.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26B24120020; Sat, 24 Aug 2019 12:53:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AhvknYUpM2mOlyhkg9aYde4+YCi+INBFbhmOpS7PU7GMpoemdVCly9uC2cBd/StXbA1CnGdBwFP7KfkcBil7CohUWFV2+GxTJ22ZiWO/6FzSAO8fElSVq1HocBAFUJ4Zr7vET+p/MHosORZGzowSSYy8qPLYEqBG/e2I3lBO5wg2RGHPf/iHD2+UxnSZQPzjRC0KXaxkEP+G4zSs377fS4Qe/VERa0bHaPOlembd5MJUSumcZZx0cvFHANTH9bV1e9V0lmuZUQpxYt+FQoe2O+TpNq8C8s/29hgQAg5nWvVlQeyXVgxcNcdH2AJRM61lAIZnllpQIEhw/Ao5jndqtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pnvLoIMZLD/NGH2q8pVVxPg1iux11ZMeEw6Sb8veD7Q=; b=RBNd0WrLcnsDcVyDJwa4UFlhRyoxGdSiRN8Z2MQgpJfrMrcgWHMyvW9lUC0lJzhtVxwap75mdWMb2fFmp5lA2sXwsXFoJEV9pr5OW/ywt7k9Aek1ZxMsGe7sVlD5wpMmXruu6eNFswpNP2L3HRFdw3fBTB400M1QmMv1/oDoPVHxdq0CZzUyX9p9dYEZ/RRpwpQVpmtHxkg3gUxPOSGmgFQ80wXqmatrXcKQ/7brVhtuOhIa87PG1MUOTwm6kdl6HlpF9dxM8QKkzsJ2xyhpfatCZ3UI6qeAzWiECCUcfpw2FEeRdd81fELnXKMm1/tICXfhhbYvqK2FZqY2/rFIAQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pnvLoIMZLD/NGH2q8pVVxPg1iux11ZMeEw6Sb8veD7Q=; b=KkcZkFAoqqhRNZ4P9PRs/b0n8wZYqUm2yxavHMflncLegO9NpJxkABZOCLYRIK8wd8YIuhyx8yrjvwfhAyigxbdydZWaCQmU7rfvAZH/tjKbTu0gC7UTbUAe1YirNUW58S1aNWFs+ByZ8bsUciqhJgI/MFjaiWjXNG7dKPfWlFnfckhJKp+2DDNBA8pXsk89t5v9ZO7pXteS5so/QtANxo0afbSIidOel4UWGLDwgtTkf2hn9aZjjsOTkaB2uGEnp1NEngAQ27op4dkZVwITaLb2s543OrZtSwr1tBxxZcWU6eaytXdvpyPZn477Y4OYG3k7ggYhsgU0v0HP/EVL8Q== Received: from SN1NAM02FT013.eop-nam02.prod.protection.outlook.com (10.152.72.56) by SN1NAM02HT059.eop-nam02.prod.protection.outlook.com (10.152.73.45) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.13; Sat, 24 Aug 2019 19:53:11 +0000 Received: from MWHPR04MB0367.namprd04.prod.outlook.com (10.152.72.57) by SN1NAM02FT013.mail.protection.outlook.com (10.152.72.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.13 via Frontend Transport; Sat, 24 Aug 2019 19:53:10 +0000 Received: from MWHPR04MB0367.namprd04.prod.outlook.com ([fe80::647b:b636:342c:f0f5]) by MWHPR04MB0367.namprd04.prod.outlook.com ([fe80::647b:b636:342c:f0f5%2]) with mapi id 15.20.2178.020; Sat, 24 Aug 2019 19:53:10 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-ecrit-data-only-ea.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-ecrit-data-only-ea-18 Thread-Index: AQHVWrVSYrXYcnS0SkGl7pu26H6ueQ== Date: Sat, 24 Aug 2019 19:53:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:1F1FED9EAFBA0D4184881D4ACE6AD383884967CEFDE737BBA1E7670C646DC028; UpperCasedChecksum:30B068DF2CCF5B9A043DAF63945B690001059E4739F467AEF8CA51728D220CA4; SizeAsReceived:6714; Count:40 x-tmn: [YdBoR6aQ3yP5WuHc5mzl14h77OcZUwaC] x-ms-publictraffictype: Email x-incomingheadercount: 40 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(5050001)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031323274)(2017031324274)(2017031322404)(1601125500)(1603101475)(1701031045); SRVR:SN1NAM02HT059; x-ms-traffictypediagnostic: SN1NAM02HT059: x-microsoft-antispam-message-info: DlSZsmLs0WXTO0vMBSDSgsyZyR5UilZrvRvdkAOBlBbE716xAkLX40ApgSMKXkuV8iqcqbuYRHhU6n46eNWKgXNWEBgnpUAP//zME5W96sxVDgPRsXER9M8s1FonEc3cazWT4CjHEsh/cwK7NQQ0bcPP3Cd2zpA9hanP5WMPifHJgYsLUSaYqDUwwvQB2Grk x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MWHPR04MB0367DA96CF172D996CDDA622DFA70MWHPR04MB0367namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 12ed7498-8e5b-43f5-2095-08d728ccb0fa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2019 19:53:10.2366 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT059 Resent-From: Resent-To: br@brianrosen.net, hgs+ecrit@cs.columbia.edu, hannes.tschofenig@arm.com, rg+ietf@coretechnologyconsulting.com, allison.mankin@gmail.com, roger.marshall@comtechtel.com, barryleiba@computer.org, adam@nostrum.com, aamelnikov@fastmail.fm, Allison Mankin , draft-ietf-ecrit-data-only-ea@ietf.org, ecrit@ietf.org Resent-Message-Id: <20190824195315.23205120020@ietfa.amsl.com> Resent-Date: Sat, 24 Aug 2019 12:53:15 -0700 (PDT) Archived-At: Subject: [Ecrit] Secdir review of draft-ietf-ecrit-data-only-ea-18 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2019 19:53:15 -0000 --_000_MWHPR04MB0367DA96CF172D996CDDA622DFA70MWHPR04MB0367namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document defines a new MIME type: 'application/EmergencyCallData.cap+x= ml' for use primarily by sensors to send alert messages to emergency servic= es providers. It also defines a new Emergency Call Data Type: 'cap' in orde= r to embed this data efficiently in a SIP transaction. I saw no new securit= y issues beyond those already noted for the protocols carrying these messag= es. I do have some editorial suggestions: There is a lot of context that the authors assumed any reader would have th= at could have been stated in the introduction. I believe from context that = the purpose of this new MIME type is to support simple (IoT) sensors that d= on't want to implement a more heavyweight protocol, but I don't believe tha= t was stated anywhere. I got the impression that the functionality provided could have been done w= ith existing protocols by sending the CAP message over a SIP session, but t= hat doing so would place an unnecessary burden on simple (IoT) sensors, and= that this protocol would be easier for such sensors to implement for the l= imited cases such sensors need to deal with. If that's true, it should be s= tated. If not, the purpose of this protocol should be more clearly stated. These acronyms were used but never defined: SIP CID LoST These acronyms were expanded, but not in an easy to find place: Common Alerting Protocol (CAP) Public Safety Answering Points (PSAPs) Emergency Services Routing Proxy (ESRP) It would be nice to include them in the terminology section, ideally with a= reference to the RFC where more information is available. Typo: p17 "security mechanism" -> "security mechanisms" --Charlie --_000_MWHPR04MB0367DA96CF172D996CDDA622DFA70MWHPR04MB0367namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security directorate's on= going effort to review all IETF documents being processed by the IESG. = ; These comments were written primarily for the benefit of the security are= a directors.  Document editors and WG chairs should treat these comments just like any other last call comments.=

This document defines a new MIME type: 'application/EmergencyCallData.= cap+xml' for use primarily by sensors to send alert messages to emergen= cy services providers. It also defines a new Emergency Call Data Type: 'cap= ' in order to embed this data efficiently in a SIP transaction. I saw no new security issues beyond those already no= ted for the protocols carrying these messages.

I do have some editorial suggestions:

There is a lot of context that the authors assumed any reader would ha= ve that could have been stated in the introduction. I believe from context = that the purpose of this new MIME type is to support simple (IoT) sensors t= hat don't want to implement a more heavyweight protocol, but I don't believe that was stated anywhere.

I got the impression that the functionality provided could have been d= one with existing protocols by sending the CAP message over a SIP session, = but that doing so would place an unnecessary burden on simple (IoT) sensors= , and that this protocol would be easier for such sensors to implement for the limited cases such sensors ne= ed to deal with. If that's true, it should be stated. If not, the purpose o= f this protocol should be more clearly stated.

These acronyms were used but never defined:

SIP
CID
LoST

These acronyms were expanded, but not in an easy to find place:

Common Alerting Protocol (CAP)
Public Safety Answering Points (PSAPs)
Emergency Services Routing Proxy (ESRP)

It would be nice to include them in the terminology section, ideally w= ith a reference to the RFC where more information is available.

Typo:

p17 "security mechanism" -> "security mechanisms&quo= t;

 --Charlie

--_000_MWHPR04MB0367DA96CF172D996CDDA622DFA70MWHPR04MB0367namp_-- From nobody Sat Aug 24 14:18:34 2019 Return-Path: X-Original-To: expand-draft-ietf-ecrit-data-only-ea.all@virtual.ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 9EA1F12006D; Sat, 24 Aug 2019 14:18:17 -0700 (PDT) X-Original-To: xfilter-draft-ietf-ecrit-data-only-ea.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-ecrit-data-only-ea.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43AED120088; Sat, 24 Aug 2019 14:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 z0O22P_qXfyD; Sat, 24 Aug 2019 14:18:14 -0700 (PDT) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 D79A212006D; Sat, 24 Aug 2019 14:18:14 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id p3so7950613pgb.9; Sat, 24 Aug 2019 14:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A3FB0rgL5uNCXbL9iJtguwuP4RJOxdtpuP05UwSIrPg=; b=GafuO7dSlA4mcMGwcoQ+dA1sdASfKX9zA6t/BW+5NdE//dEV19K/yURDg7xxoM5Lv3 d7KemYHrELwejbnNaSkO9t3LAiCwzDAwAp4jjD9CK+bB5x84UxqPpLM6OJ5/kaTuDpGE 92FrNb216FjF7Ho6SaLnJSeRO5erzFB0Qkpm0DPoC28OnuyzcxPk9pacBqtEX0PVb98w qt/aUMvcEHEJUDPHvGVDzUuO0u8lCxMzwPxWDKYjHldcUlQUkk7YLe4RGdQAO3Rbb+XN ha32xEHSRnw+CUnp0VG5/9+V8EyLcCchCtH60de/1tbwdp5wSa56fHbfdLhB+mpQDPYU Kqtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A3FB0rgL5uNCXbL9iJtguwuP4RJOxdtpuP05UwSIrPg=; b=mZxLQ5ezXD6BfDo5ikbFtP6Vsbj8KU36+wu9+D6jE7NBCQkzSEWWqnbWMWcbh/Eyy0 mIKPB9XTXsRcgPpR25cSYStxfr2Xb1lN5BsEiTRVdPZcFGo2i5qLPL1QdYsnIhOrwrmX 5gwIr5XBSZowJ51H4HxFlN/sqAjtIzgC6yGfMpFszkHB9jy9IlNPaEM69h/1B/Ju6utD 1eeLCBDnaKkPh2q/6e9/Ogghe2KDmsEHQfsnGbN6JOnCHanRPV8f853dM+RTIFXdZ53B /FtavnwZlUTxH2jxcMMGtGSgdfl3lUmZyJO5FOH6LC+k2VAJ6UKBjQyCv3zpi26rGx6w R7ZA== X-Gm-Message-State: APjAAAXd9ePHMo75Q0bXJ0uXtS4qFM27d4+9Xt3IR9TqnWoosK1Y+Dnr dMgBBNnXFM+iwsgk6OEO81FEXvBeQJbIp13+Bbo= X-Google-Smtp-Source: APXvYqx6+3yEn4HjGxS8Mck0njhon2EfGSDEoh8gfgnjksIsMlbMkeQHrAuzpiYcrNTtpw23ejNFuSTS23OY6Cfn4WM= X-Received: by 2002:a63:61cd:: with SMTP id v196mr9747340pgb.263.1566681494027; Sat, 24 Aug 2019 14:18:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Allison Mankin Date: Sat, 24 Aug 2019 17:18:03 -0400 Message-ID: To: Charlie Kaufman Cc: "draft-ietf-ecrit-data-only-ea.all@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ed831f0590e375f4" Resent-From: Resent-To: br@brianrosen.net, hgs+ecrit@cs.columbia.edu, hannes.tschofenig@arm.com, rg+ietf@coretechnologyconsulting.com, allison.mankin@gmail.com, roger.marshall@comtechtel.com, barryleiba@computer.org, adam@nostrum.com, aamelnikov@fastmail.fm, Allison Mankin , draft-ietf-ecrit-data-only-ea@ietf.org, ecrit@ietf.org Resent-Message-Id: <20190824211817.9EA1F12006D@ietfa.amsl.com> Resent-Date: Sat, 24 Aug 2019 14:18:17 -0700 (PDT) Archived-At: Subject: Re: [Ecrit] Secdir review of draft-ietf-ecrit-data-only-ea-18 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2019 21:18:18 -0000 --000000000000ed831f0590e375f4 Content-Type: text/plain; charset="UTF-8" Thank you, Charlie. Authors, these are good suggestions! On Sat, Aug 24, 2019 at 15:53 Charlie Kaufman wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments. > > This document defines a new MIME type: > 'application/EmergencyCallData.cap+xml' for use primarily by sensors to > send alert messages to emergency services providers. It also defines a new > Emergency Call Data Type: 'cap' in order to embed this data efficiently in > a SIP transaction. I saw no new security issues beyond those already noted > for the protocols carrying these messages. > > I do have some editorial suggestions: > > There is a lot of context that the authors assumed any reader would have > that could have been stated in the introduction. I believe from context > that the purpose of this new MIME type is to support simple (IoT) sensors > that don't want to implement a more heavyweight protocol, but I don't > believe that was stated anywhere. > > I got the impression that the functionality provided could have been done > with existing protocols by sending the CAP message over a SIP session, but > that doing so would place an unnecessary burden on simple (IoT) sensors, > and that this protocol would be easier for such sensors to implement for > the limited cases such sensors need to deal with. If that's true, it should > be stated. If not, the purpose of this protocol should be more clearly > stated. > > These acronyms were used but never defined: > > SIP > CID > LoST > > These acronyms were expanded, but not in an easy to find place: > > Common Alerting Protocol (CAP) > Public Safety Answering Points (PSAPs) > Emergency Services Routing Proxy (ESRP) > > It would be nice to include them in the terminology section, ideally with > a reference to the RFC where more information is available. > > Typo: > > p17 "security mechanism" -> "security mechanisms" > > --Charlie > > --000000000000ed831f0590e375f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you, Charlie. Authors, these are good suggesti= ons!

On Sat, Aug 24, 2019 at 15:53 Charlie Kaufman <charliekaufman@outlook.com> w= rote:
I have reviewed this document as part of the security directorate'= s ongoing effort to review all IETF documents being processed by the IESG.= =C2=A0 These comments were written primarily for the benefit of the securit= y area directors.=C2=A0 Document editors and WG chairs should treat these comments just like any other last call comments.=

This document defines a new MIME type: 'application/EmergencyCallD= ata.cap+xml' for use primarily by sensors to send alert messages to eme= rgency services providers. It also defines a new Emergency Call Data Type: = 'cap' in order to embed this data efficiently in a SIP transaction. I saw no new security issues beyond those already no= ted for the protocols carrying these messages.

I do have some editorial suggestions:

There is a lot of context that the authors assumed any reader would ha= ve that could have been stated in the introduction. I believe from context = that the purpose of this new MIME type is to support simple (IoT) sensors t= hat don't want to implement a more heavyweight protocol, but I don't believe that was stated anywhere.

I got the impression that the functionality provided could have been d= one with existing protocols by sending the CAP message over a SIP session, = but that doing so would place an unnecessary burden on simple (IoT) sensors= , and that this protocol would be easier for such sensors to implement for the limited cases such sensors ne= ed to deal with. If that's true, it should be stated. If not, the purpo= se of this protocol should be more clearly stated.

These acronyms were used but never defined:

SIP
CID
LoST

These acronyms were expanded, but not in an easy to find place:

Common Alerting Protocol (CAP)
Public Safety Answering Points (PSAPs)
Emergency Services Routing Proxy (ESRP)

It would be nice to include them in the terminology section, ideally w= ith a reference to the RFC where more information is available.

Typo:

p17 "security mechanism" -> "security mechanisms&quo= t;

=C2=A0--Charlie

--000000000000ed831f0590e375f4-- From nobody Mon Aug 26 13:35:09 2019 Return-Path: X-Original-To: expand-draft-ietf-ecrit-data-only-ea.all@virtual.ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id A522512011C; Mon, 26 Aug 2019 13:34:55 -0700 (PDT) X-Original-To: xfilter-draft-ietf-ecrit-data-only-ea.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-ecrit-data-only-ea.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22BB212011C for ; Mon, 26 Aug 2019 13:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 rc6MMBxq5pv0 for ; Mon, 26 Aug 2019 13:34:52 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 BF947120EE0 for ; Mon, 26 Aug 2019 13:34:51 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id m10so15217687qkk.1 for ; Mon, 26 Aug 2019 13:34:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=G9QH4iFldqe77/C4KQH64rjdHhzNbEj0ujVfUaz9gzw=; b=17hBjENo7PYczx13zt0V5ulCr+xGZUsAGG8bg7+IjMR8rJllKIi5R7fZsObmIRxYc3 v0z5GoKVjt4LcBzCm+6zAjyWG/4/Yi9LO36CAH86W6B/mk1EpMIIiNMCfik9UgPgP1AU EFPfjeWrWkhET4cZ0r+FMzyb8IxUdn3fcWBwFu1I9jID7oHOXA2fQLyipGZ45bNmdQdq 6xbJaKjsTyIkNuTna97SmuzHsTzvptVpCjTO4aU5wsm20V21g57iVX6wX8/tGpDAGaIZ nYMMkXDCDFQm7FyMN+bfddEa9c9qH094221I8K9scEpHoyD9JPbzW3GVQl0vU4j7T3Yc htfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=G9QH4iFldqe77/C4KQH64rjdHhzNbEj0ujVfUaz9gzw=; b=rBIsL/ozofqPTFqd+QCXoue15Ji2kbtJvNswIMwF3wt1R6jt7Alw+hi9LvQMVpuqOc D8G6AGIxaLQ5Prbxxhz2GaHj6axLaN2uXZT0YVKHqVEZyHBZks7bQhGYYOTmk6+heuTA kQWrxPDM6t0zCfQpW1cig+fIlDIz8WMybG1l/EH42rMEvmWpmx7+Gj4BMSlD20u9CWlV apDS6sQR17kkE+eXK3iVHh1rhK/J1KCjo+BM8OM13kvO083oQyxlYQSxX43iAAoXXxQ3 j+d6T3MprWQnCeJiA2dQ6vS2rJ63ZaalZ1FhKxp+mUt39KIty2csL3Al9+bDrKdlFUiS jllg== X-Gm-Message-State: APjAAAXtoFYDR67Unagghwv/CSR+XHVos7+pMGAOmT8ng62f1KYEd+pe 5BULNXrNlkjODhywtpCsTT5s6w== X-Google-Smtp-Source: APXvYqzTM0YWioaYz2Mywh/36dhPpaCCb+B38WXTTm0CkXJ/NgcVK2G+FXRvpG3sNnKBWwMzlIPyiQ== X-Received: by 2002:a37:9b48:: with SMTP id d69mr18733327qke.449.1566851690724; Mon, 26 Aug 2019 13:34:50 -0700 (PDT) Received: from brians-mbp-2369.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id 145sm7134511qkm.1.2019.08.26.13.34.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Aug 2019 13:34:50 -0700 (PDT) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_26D64576-1C1A-4C42-AB7C-6D56AFA05284" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 26 Aug 2019 16:34:49 -0400 In-Reply-To: Cc: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-ecrit-data-only-ea.all@ietf.org" To: Charlie Kaufman References: X-Mailer: Apple Mail (2.3445.104.11) Resent-From: Resent-To: br@brianrosen.net, hgs+ecrit@cs.columbia.edu, hannes.tschofenig@arm.com, rg+ietf@coretechnologyconsulting.com, allison.mankin@gmail.com, roger.marshall@comtechtel.com, barryleiba@computer.org, adam@nostrum.com, aamelnikov@fastmail.fm, Allison Mankin , draft-ietf-ecrit-data-only-ea@ietf.org, ecrit@ietf.org Resent-Message-Id: <20190826203455.A522512011C@ietfa.amsl.com> Resent-Date: Mon, 26 Aug 2019 13:34:55 -0700 (PDT) Archived-At: Subject: Re: [Ecrit] Secdir review of draft-ietf-ecrit-data-only-ea-18 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 20:34:59 -0000 --Apple-Mail=_26D64576-1C1A-4C42-AB7C-6D56AFA05284 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Charlie Thanks for the review, I appreciate it. The introduction section has this text Data-only emergency calls are similar to regular emergency calls in the sense that they require the emergency indications, emergency call routing functionality and may even have the same location requirements. However, the communication interaction will not lead to the exchange of interactive media, that is, Real-Time Protocol packets, such as voice, video data or real-time text. ... This document describes a method of including a CAP message in a SIP transaction by defining it as a block of "additional data" as defined in [RFC7852 ]. The CAP message = is included either by value (the CAP message is in the body of the message, using a CID) or by reference (a URI is included in the message, which when dereferenced returns the CAP message). The additional data mechanism is also used to send alert specific data beyond that available in the CAP message. This document also describes how a SIP MESSAGE [RFC3428 = ] transaction can be used to send a data-only call. This says that this document describes how to send an emergency call = when there is not two way interactive media (voice, video and/or text), = and it says that the way you do that is to send a SIP MESSAGE, with a = CAP message pointed to by a Call-Info header. That text seems very clear to me, and yet you didn=E2=80=99t read what = we hoped into what we wrote. I would really like to fix this, but I=E2=80= =99m at a loss to understand what I need to do. I=E2=80=99ll improve the acronym stuff. > On Aug 24, 2019, at 3:53 PM, Charlie Kaufman = wrote: >=20 > I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. >=20 > This document defines a new MIME type: = 'application/EmergencyCallData.cap+xml' for use primarily by sensors to = send alert messages to emergency services providers. It also defines a = new Emergency Call Data Type: 'cap' in order to embed this data = efficiently in a SIP transaction. I saw no new security issues beyond = those already noted for the protocols carrying these messages. >=20 > I do have some editorial suggestions: >=20 > There is a lot of context that the authors assumed any reader would = have that could have been stated in the introduction. I believe from = context that the purpose of this new MIME type is to support simple = (IoT) sensors that don't want to implement a more heavyweight protocol, = but I don't believe that was stated anywhere. >=20 > I got the impression that the functionality provided could have been = done with existing protocols by sending the CAP message over a SIP = session, but that doing so would place an unnecessary burden on simple = (IoT) sensors, and that this protocol would be easier for such sensors = to implement for the limited cases such sensors need to deal with. If = that's true, it should be stated. If not, the purpose of this protocol = should be more clearly stated. >=20 > These acronyms were used but never defined: >=20 > SIP > CID > LoST >=20 > These acronyms were expanded, but not in an easy to find place: >=20 > Common Alerting Protocol (CAP) > Public Safety Answering Points (PSAPs) > Emergency Services Routing Proxy (ESRP) >=20 > It would be nice to include them in the terminology section, ideally = with a reference to the RFC where more information is available. >=20 > Typo: >=20 > p17 "security mechanism" -> "security mechanisms" >=20 > --Charlie --Apple-Mail=_26D64576-1C1A-4C42-AB7C-6D56AFA05284 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Charlie

Thanks for = the review, I appreciate it.

The introduction section has this = text
   Data-only emergency =
calls are similar to regular emergency calls in
   the sense that they require the emergency indications, emergency call
   routing functionality and may even have the same location
   requirements.  However, the communication interaction will not lead
   to the exchange of interactive media, that is, Real-Time Protocol
   packets, such as voice, video data or real-time text.

   ...

   This document describes a method of including a CAP message in a SIP
   transaction by defining it as a block of "additional data" as defined
   in [RFC7852].  The CAP message is included either by value =
(the CAP
   message is in the body of the message, using a CID) or by reference
   (a URI is included in the message, which when dereferenced returns
   the CAP message).  The additional data mechanism is also used to send
   alert specific data beyond that available in the CAP message.  This
   document also describes how a SIP MESSAGE [RFC3428] transaction can
   be used to send a data-only call.


This says that this document describes how to send an = emergency call when there is not two way interactive media (voice, video = and/or text), and it says that the way you do that is to send a SIP = MESSAGE, with a CAP message pointed to by a Call-Info header.

That text seems very = clear to me, and yet you didn=E2=80=99t read what we hoped into what we = wrote.  I would really like to fix this, but I=E2=80=99m at a loss = to understand what I need to do.

I=E2=80=99ll improve the acronym = stuff.


On Aug 24, 2019, at 3:53 PM, = Charlie Kaufman <charliekaufman@outlook.com> wrote:

I have reviewed this document as part of the security = directorate's ongoing effort to review all IETF documents being = processed by the IESG.  These comments were written primarily for = the benefit of the security area directors.  Document editors and = WG chairs should treat these comments just like any other last call = comments.

This = document defines a new MIME type: = 'application/EmergencyCallData.cap+xml' for use primarily by sensors to = send alert messages to emergency services providers. It also defines a = new Emergency Call Data Type: 'cap' in order to embed this data = efficiently in a SIP transaction. I saw no new security issues beyond = those already noted for the protocols carrying these messages.

I do have some editorial = suggestions:

There is a lot of context that the authors assumed any reader = would have that could have been stated in the introduction. I believe = from context that the purpose of this new MIME type is to support simple = (IoT) sensors that don't want to implement a more heavyweight protocol, = but I don't believe that was stated anywhere.

I got the impression that the = functionality provided could have been done with existing protocols by = sending the CAP message over a SIP session, but that doing so would = place an unnecessary burden on simple (IoT) sensors, and that this = protocol would be easier for such sensors to implement for the limited = cases such sensors need to deal with. If that's true, it should be = stated. If not, the purpose of this protocol should be more clearly = stated.

These = acronyms were used but never defined:

SIP
CID
LoST

These acronyms were expanded, but not in an easy to find = place:

Common = Alerting Protocol (CAP)
Public Safety Answering Points = (PSAPs)
Emergency Services Routing Proxy (ESRP)

It would be nice to = include them in the terminology section, ideally with a reference to the = RFC where more information is available.

Typo:

p17 "security mechanism" -> = "security mechanisms"

 --Charlie

= --Apple-Mail=_26D64576-1C1A-4C42-AB7C-6D56AFA05284-- From nobody Wed Aug 28 06:38:49 2019 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C3D120178; Wed, 28 Aug 2019 06:38:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Mohit Sethi via Datatracker To: Cc: draft-ietf-ecrit-data-only-ea.all@ietf.org, ietf@ietf.org, ecrit@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Mohit Sethi Message-ID: <156699952808.32349.1850578807441184126@ietfa.amsl.com> Date: Wed, 28 Aug 2019 06:38:48 -0700 Archived-At: Subject: [Ecrit] Genart last call review of draft-ietf-ecrit-data-only-ea-18 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 13:38:48 -0000 Reviewer: Mohit Sethi Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ecrit-data-only-ea-18 Reviewer: Mohit Sethi Review Date: 2019-08-28 IETF LC End Date: 2019-09-02 IESG Telechat date: Not scheduled for a telechat Summary: This draft is almost ready for publication, but has some issues that concern me. The most important one is the choice of the term "data-only". Major issues: I am unsure why the authors and the WG chose the term data-only emergency call? First, I thought that it is referring to a unidirectional call but that isn't the case here. Also, aren't interactive RTP sessions also essentially composed of data packets? Perhaps notification-only and/or non-interative emergency calls could be considered as an alternative. Minor issues: The text says "A PSAP, for example, is likely to receive and accept alerts from entities it cannot authorize.". Is authorize the correct word? did you mean authenticate? You need to authenticate before you authorize. parameter: MAY contain additional information. Is it ASCII? How long can it be? I presume that the CAP has some clearler guideline. At least you could write that the CAP restrictions apply The text says something about PIDF-LO structure referenced by? I am not sure what is meant here? Perhaps some more text here would help the reader understand better. The text says "A SIP intermediary can also reject an alert it receives from a User Agent (UA) when it understands that the provided alert is malformed.". Perhaps detects is better choice than understand. It cannot understand something that is malformed. Nits/editorial comments: citizen/individual -> citizens/individuals Sending a non-interactive call containing only data toward a -> only data towards a Figures 1 and 2 could have more info. Is it a HTTP or SIP 200 (OK)? and the recipient using HTTPS to retrieve the data. -> and the recipient uses HTTPS to retrieve the data. From nobody Wed Aug 28 06:39:11 2019 Return-Path: X-Original-To: expand-draft-ietf-ecrit-data-only-ea.all@virtual.ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 86474120132; Wed, 28 Aug 2019 06:38:48 -0700 (PDT) X-Original-To: draft-ietf-ecrit-data-only-ea.all@ietf.org Delivered-To: xfilter-draft-ietf-ecrit-data-only-ea.all@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C3D120178; Wed, 28 Aug 2019 06:38:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Mohit Sethi via Datatracker To: Cc: draft-ietf-ecrit-data-only-ea.all@ietf.org, ietf@ietf.org, ecrit@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Mohit Sethi Message-ID: <156699952808.32349.1850578807441184126@ietfa.amsl.com> Date: Wed, 28 Aug 2019 06:38:48 -0700 Resent-From: Resent-To: br@brianrosen.net, hgs+ecrit@cs.columbia.edu, hannes.tschofenig@arm.com, rg+ietf@coretechnologyconsulting.com, allison.mankin@gmail.com, roger.marshall@comtechtel.com, barryleiba@computer.org, adam@nostrum.com, aamelnikov@fastmail.fm, Allison Mankin , draft-ietf-ecrit-data-only-ea@ietf.org, ecrit@ietf.org Resent-Message-Id: <20190828133848.86474120132@ietfa.amsl.com> Resent-Date: Wed, 28 Aug 2019 06:38:48 -0700 (PDT) Archived-At: Subject: [Ecrit] Genart last call review of draft-ietf-ecrit-data-only-ea-18 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 13:38:49 -0000 Reviewer: Mohit Sethi Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ecrit-data-only-ea-18 Reviewer: Mohit Sethi Review Date: 2019-08-28 IETF LC End Date: 2019-09-02 IESG Telechat date: Not scheduled for a telechat Summary: This draft is almost ready for publication, but has some issues that concern me. The most important one is the choice of the term "data-only". Major issues: I am unsure why the authors and the WG chose the term data-only emergency call? First, I thought that it is referring to a unidirectional call but that isn't the case here. Also, aren't interactive RTP sessions also essentially composed of data packets? Perhaps notification-only and/or non-interative emergency calls could be considered as an alternative. Minor issues: The text says "A PSAP, for example, is likely to receive and accept alerts from entities it cannot authorize.". Is authorize the correct word? did you mean authenticate? You need to authenticate before you authorize. parameter: MAY contain additional information. Is it ASCII? How long can it be? I presume that the CAP has some clearler guideline. At least you could write that the CAP restrictions apply The text says something about PIDF-LO structure referenced by? I am not sure what is meant here? Perhaps some more text here would help the reader understand better. The text says "A SIP intermediary can also reject an alert it receives from a User Agent (UA) when it understands that the provided alert is malformed.". Perhaps detects is better choice than understand. It cannot understand something that is malformed. Nits/editorial comments: citizen/individual -> citizens/individuals Sending a non-interactive call containing only data toward a -> only data towards a Figures 1 and 2 could have more info. Is it a HTTP or SIP 200 (OK)? and the recipient using HTTPS to retrieve the data. -> and the recipient uses HTTPS to retrieve the data. From nobody Wed Aug 28 08:53:51 2019 Return-Path: X-Original-To: expand-draft-ietf-ecrit-data-only-ea.all@virtual.ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id CE7A5120131; Wed, 28 Aug 2019 08:53:43 -0700 (PDT) X-Original-To: xfilter-draft-ietf-ecrit-data-only-ea.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-ecrit-data-only-ea.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686C4120219 for ; Wed, 28 Aug 2019 08:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 E4tD_4E7MOYe for ; Wed, 28 Aug 2019 08:53:41 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 E4BD1120131 for ; Wed, 28 Aug 2019 08:53:40 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id 4so177837qki.6 for ; Wed, 28 Aug 2019 08:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Z0WgX5Urn5J7fimHhebnwGGQO130bhyoi1ZJBTaMHAA=; b=bTk7fTcGO7FXLURfS2zFipLIynsalw7umPBu6TXrrl4l/U7/IzTw9BOX11mJmK7b7D i8ENo89FNvs4WaspUlo3D0uBPBo6lTfHm76RI5oM+X1sJcVt2z9NBAmXFCbbSv25tZ1s dIYNOVqZ/dZS7f9x7N0W3yq/ANGwBAcOwWLipE+BAFoUUIxVUOOSfaGleVv4MLngeLmE 4KjnP8LLbPIrd/q4CtAekRTxRJcVKiEqhWtQklGYpeFHA1s4luFJcZ937+4fr23+mR+G /52z9V/6RbxuF6QbMliuB+mm7gOIZkhH0yqg3Acr/DhW3+4JYryauYghCuWk0p7vPHTJ qjPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Z0WgX5Urn5J7fimHhebnwGGQO130bhyoi1ZJBTaMHAA=; b=RCaZThGn839NDUOY4JaLpnTHwUnRXmNhe+sAJFrNqaE2Qh3JwudJOnIxofBpwg+4AV ZVOAoQkCyAHzYW9xQi3B/DrGZzldZtf8wUXjYGXbKQQYBDv9i3auUCVEjnkPZxoIwmG4 h+0O3ixPtFMne0pm6Wd6ry/NhK+aRoKjJfZni1VY6mmC7z/H8Yxk9mxNqa2Ab7RZQDn4 CHg3/VHYVs8wJVKqMTGnzLik3wArboJmeCmcc3S7EM1J7LGZD6ui0aGvTkJ0X0a4ydfk r2m5RSsQYyqEAKWqi1t1q1mOHgS5TyUzImTeUpJPTUWsF/gSVZ+vsCFOqY62bpSRlvVa bqSg== X-Gm-Message-State: APjAAAXhfr0/ciQ/xWc/w7YoQozLvtlI3ipUaxYLwjQJocNBOXhOAJcw Mn2P6TZ0kqXsaft2le1WiEAO1A== X-Google-Smtp-Source: APXvYqxvocaDMBDcDfFQIZUz5WvdQOpV9aImsqRj4uy2uVGl3H+nnR+b8i6arzDfE131J5h9MC65HA== X-Received: by 2002:a37:6390:: with SMTP id x138mr4753296qkb.222.1567007619886; Wed, 28 Aug 2019 08:53:39 -0700 (PDT) Received: from brians-mbp-2369.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id x28sm1480517qtk.8.2019.08.28.08.53.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Aug 2019 08:53:39 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Brian Rosen In-Reply-To: <156699952808.32349.1850578807441184126@ietfa.amsl.com> Date: Wed, 28 Aug 2019 11:53:37 -0400 Cc: gen-art@ietf.org, draft-ietf-ecrit-data-only-ea.all@ietf.org, ietf@ietf.org, ecrit@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <156699952808.32349.1850578807441184126@ietfa.amsl.com> To: Mohit Sethi X-Mailer: Apple Mail (2.3445.104.11) Resent-From: Resent-To: br@brianrosen.net, hgs+ecrit@cs.columbia.edu, hannes.tschofenig@arm.com, rg+ietf@coretechnologyconsulting.com, allison.mankin@gmail.com, roger.marshall@comtechtel.com, barryleiba@computer.org, adam@nostrum.com, aamelnikov@fastmail.fm, Allison Mankin , draft-ietf-ecrit-data-only-ea@ietf.org, ecrit@ietf.org Resent-Message-Id: <20190828155343.CE7A5120131@ietfa.amsl.com> Resent-Date: Wed, 28 Aug 2019 08:53:43 -0700 (PDT) Archived-At: Subject: Re: [Ecrit] Genart last call review of draft-ietf-ecrit-data-only-ea-18 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 15:53:44 -0000 Thank you very much for your review. The term we use for these kinds of =E2=80=9Ccalls=E2=80=9D has changed = several times. There really isn=E2=80=99t a great name. In another forum, we=E2=80=99re calling them =E2=80=9Cnon-human-initiated=E2= =80=9D, but that really isn=E2=80=99t right either. If you press a = button and a device sends your location and some medical data, then it = IS human initiated. The differentiation that matters is whether there is two way interactive = media or not, which also means whether there is a session or not.=20 Most of these =E2=80=9Ccalls=E2=80=9D will be from sensors, and really = are data-only, and I think the differentiation between data and media is = clear and not confusing. But you could have one way, non interactive = media signaled with these calls (a surveillance camera for example). = The call would be session-less. The camera information would be passed = as a URI to an RTSP media stream, so what is passed really is data (the = URL) and not the media, but there IS media involved, so =E2=80=9Cdata-only= =E2=80=9D isn=E2=80=99t great. =E2=80=9CNon Interactive=E2=80=9D may also not be quite right: If an = elevator sends you an alert and also gives responders access to control = it, is that interactive? The =E2=80=9Ccall=E2=80=9D isn=E2=80=99t, but = the name could be misleading. In the end, I don=E2=80=99t think changing the name is worth while. = It=E2=80=99s fairly accurate, not confusing. I=E2=80=99d be okay with = changing it to =E2=80=9CNon-Human-Initiated=E2=80=9D, but that has = problems also. I will take this discussion back to the work group = though, =E2=80=9CAuthorize=E2=80=9D really is the right word. We may be able to = authenticate you (using stir for example), but we usually don=E2=80=99t = have any authorization mechanism - unless we=E2=80=99re under attack, we = take calls from anyone. That=E2=80=99s the nature of emergency calls. = In the US, you can get an emergency call from a mobile that has no = service. I=E2=80=99ll do the edits for the additional information in the = parameter. PIDF-LO is how emergency calls send location. I=E2=80=99ll = improve that text. Also will substitute =E2=80=9Cdetects=E2=80=9D for = =E2=80=9Cunderstands=E2=80=9D and fix the nits. Brian > On Aug 28, 2019, at 9:38 AM, Mohit Sethi via Datatracker = wrote: >=20 > Reviewer: Mohit Sethi > Review result: Ready with Issues >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-ecrit-data-only-ea-18 > Reviewer: Mohit Sethi > Review Date: 2019-08-28 > IETF LC End Date: 2019-09-02 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: This draft is almost ready for publication, but has some = issues that > concern me. The most important one is the choice of the term = "data-only". >=20 > Major issues: I am unsure why the authors and the WG chose the term = data-only > emergency call? First, I thought that it is referring to a = unidirectional call > but that isn't the case here. Also, aren't interactive RTP sessions = also > essentially composed of data packets? >=20 > Perhaps notification-only and/or non-interative emergency calls could = be > considered as an alternative. >=20 > Minor issues: The text says "A PSAP, for example, is likely to receive = and > accept alerts from entities it cannot authorize.". Is authorize the = correct > word? did you mean authenticate? You need to authenticate before you = authorize. >=20 > parameter: MAY contain additional information. Is it ASCII? How long = can it be? > I presume that the CAP has some clearler guideline. At least you could = write > that the CAP restrictions apply >=20 > The text says something about PIDF-LO structure referenced by? I am = not sure > what is meant here? Perhaps some more text here would help the reader > understand better. >=20 > The text says "A SIP intermediary can also reject an alert it receives = from a > User Agent (UA) when it understands that the provided alert is = malformed.". > Perhaps detects is better choice than understand. It cannot understand > something that is malformed. >=20 > Nits/editorial comments: >=20 > citizen/individual -> citizens/individuals > Sending a non-interactive call containing only data toward a -> only = data > towards a Figures 1 and 2 could have more info. Is it a HTTP or SIP = 200 (OK)? > and the recipient using HTTPS to retrieve the data. -> and the = recipient uses > HTTPS to retrieve the data. >=20 From nobody Wed Aug 28 08:54:04 2019 Return-Path: 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 38B5F1201E0 for ; Wed, 28 Aug 2019 08:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 ThPr4On_tztZ for ; Wed, 28 Aug 2019 08:53:41 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 F04091201DB for ; Wed, 28 Aug 2019 08:53:40 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id m2so134947qki.12 for ; Wed, 28 Aug 2019 08:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Z0WgX5Urn5J7fimHhebnwGGQO130bhyoi1ZJBTaMHAA=; b=bTk7fTcGO7FXLURfS2zFipLIynsalw7umPBu6TXrrl4l/U7/IzTw9BOX11mJmK7b7D i8ENo89FNvs4WaspUlo3D0uBPBo6lTfHm76RI5oM+X1sJcVt2z9NBAmXFCbbSv25tZ1s dIYNOVqZ/dZS7f9x7N0W3yq/ANGwBAcOwWLipE+BAFoUUIxVUOOSfaGleVv4MLngeLmE 4KjnP8LLbPIrd/q4CtAekRTxRJcVKiEqhWtQklGYpeFHA1s4luFJcZ937+4fr23+mR+G /52z9V/6RbxuF6QbMliuB+mm7gOIZkhH0yqg3Acr/DhW3+4JYryauYghCuWk0p7vPHTJ qjPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Z0WgX5Urn5J7fimHhebnwGGQO130bhyoi1ZJBTaMHAA=; b=Qxh3IaH0E4RbIicOvX8kxr1wgKsFBXas1InqTN/kPr9vw0piTEScG05AeKr/vACmtu 7X5gar2sdBxdoGEDhvTc8pGK9uoJwcDjW0bGkGv7S/2FcMo9QFgXyB/VWMvHbazHMp2B i9MXKNc5H1UQ82HaqBWF6VbeuuSWJj0Q46agcsMh3qs2wzax+AMcI9+qVGdZNXyFPGzl Qs7rntFu8OzBXWeNdPHT8VU745gJHRSwuL4/JfvdyEde8hb2mS6D1QP+qUQHFw2VpbNR NwGuyNouzJylw/IOClqfFOm3xV2loKEfnwmfoya33xyKmyEfk3aauWsNFybilZuKgeEj E/Mw== X-Gm-Message-State: APjAAAXGeJvKuIMfXLm/7duvhdYI4/fAABJ2aXXfJmclvWahECPbDJYu RBiLUGHcPsO/5R/YpsPaQ9BQFg== X-Google-Smtp-Source: APXvYqxvocaDMBDcDfFQIZUz5WvdQOpV9aImsqRj4uy2uVGl3H+nnR+b8i6arzDfE131J5h9MC65HA== X-Received: by 2002:a37:6390:: with SMTP id x138mr4753296qkb.222.1567007619886; Wed, 28 Aug 2019 08:53:39 -0700 (PDT) Received: from brians-mbp-2369.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id x28sm1480517qtk.8.2019.08.28.08.53.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Aug 2019 08:53:39 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Brian Rosen In-Reply-To: <156699952808.32349.1850578807441184126@ietfa.amsl.com> Date: Wed, 28 Aug 2019 11:53:37 -0400 Cc: gen-art@ietf.org, draft-ietf-ecrit-data-only-ea.all@ietf.org, ietf@ietf.org, ecrit@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <156699952808.32349.1850578807441184126@ietfa.amsl.com> To: Mohit Sethi X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Ecrit] Genart last call review of draft-ietf-ecrit-data-only-ea-18 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 15:53:44 -0000 Thank you very much for your review. The term we use for these kinds of =E2=80=9Ccalls=E2=80=9D has changed = several times. There really isn=E2=80=99t a great name. In another forum, we=E2=80=99re calling them =E2=80=9Cnon-human-initiated=E2= =80=9D, but that really isn=E2=80=99t right either. If you press a = button and a device sends your location and some medical data, then it = IS human initiated. The differentiation that matters is whether there is two way interactive = media or not, which also means whether there is a session or not.=20 Most of these =E2=80=9Ccalls=E2=80=9D will be from sensors, and really = are data-only, and I think the differentiation between data and media is = clear and not confusing. But you could have one way, non interactive = media signaled with these calls (a surveillance camera for example). = The call would be session-less. The camera information would be passed = as a URI to an RTSP media stream, so what is passed really is data (the = URL) and not the media, but there IS media involved, so =E2=80=9Cdata-only= =E2=80=9D isn=E2=80=99t great. =E2=80=9CNon Interactive=E2=80=9D may also not be quite right: If an = elevator sends you an alert and also gives responders access to control = it, is that interactive? The =E2=80=9Ccall=E2=80=9D isn=E2=80=99t, but = the name could be misleading. In the end, I don=E2=80=99t think changing the name is worth while. = It=E2=80=99s fairly accurate, not confusing. I=E2=80=99d be okay with = changing it to =E2=80=9CNon-Human-Initiated=E2=80=9D, but that has = problems also. I will take this discussion back to the work group = though, =E2=80=9CAuthorize=E2=80=9D really is the right word. We may be able to = authenticate you (using stir for example), but we usually don=E2=80=99t = have any authorization mechanism - unless we=E2=80=99re under attack, we = take calls from anyone. That=E2=80=99s the nature of emergency calls. = In the US, you can get an emergency call from a mobile that has no = service. I=E2=80=99ll do the edits for the additional information in the = parameter. PIDF-LO is how emergency calls send location. I=E2=80=99ll = improve that text. Also will substitute =E2=80=9Cdetects=E2=80=9D for = =E2=80=9Cunderstands=E2=80=9D and fix the nits. Brian > On Aug 28, 2019, at 9:38 AM, Mohit Sethi via Datatracker = wrote: >=20 > Reviewer: Mohit Sethi > Review result: Ready with Issues >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-ecrit-data-only-ea-18 > Reviewer: Mohit Sethi > Review Date: 2019-08-28 > IETF LC End Date: 2019-09-02 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: This draft is almost ready for publication, but has some = issues that > concern me. The most important one is the choice of the term = "data-only". >=20 > Major issues: I am unsure why the authors and the WG chose the term = data-only > emergency call? First, I thought that it is referring to a = unidirectional call > but that isn't the case here. Also, aren't interactive RTP sessions = also > essentially composed of data packets? >=20 > Perhaps notification-only and/or non-interative emergency calls could = be > considered as an alternative. >=20 > Minor issues: The text says "A PSAP, for example, is likely to receive = and > accept alerts from entities it cannot authorize.". Is authorize the = correct > word? did you mean authenticate? You need to authenticate before you = authorize. >=20 > parameter: MAY contain additional information. Is it ASCII? How long = can it be? > I presume that the CAP has some clearler guideline. At least you could = write > that the CAP restrictions apply >=20 > The text says something about PIDF-LO structure referenced by? I am = not sure > what is meant here? Perhaps some more text here would help the reader > understand better. >=20 > The text says "A SIP intermediary can also reject an alert it receives = from a > User Agent (UA) when it understands that the provided alert is = malformed.". > Perhaps detects is better choice than understand. It cannot understand > something that is malformed. >=20 > Nits/editorial comments: >=20 > citizen/individual -> citizens/individuals > Sending a non-interactive call containing only data toward a -> only = data > towards a Figures 1 and 2 could have more info. Is it a HTTP or SIP = 200 (OK)? > and the recipient using HTTPS to retrieve the data. -> and the = recipient uses > HTTPS to retrieve the data. >=20 From nobody Wed Aug 28 09:34:09 2019 Return-Path: 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 E2C0912018D; Wed, 28 Aug 2019 09:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 I1Cm8wDcdbbG; Wed, 28 Aug 2019 09:33:51 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00061.outbound.protection.outlook.com [40.107.0.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F0E91200B2; Wed, 28 Aug 2019 09:33:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BF93glTUz3G/t8kg7grXIdefqdgtaz9U5LWuOwgFXcshkUf1+IVIfPVXuzr4lNGWbgWXfphloKjL0uc+c57I4ISjbdZmEVYXrFVawl/p8Pu0NJpdNxMi6FgGvGnO5FBfNYRicE9FeBO7ib6joNRrhXjXqp1GEWf9zm6E5DGZRheP71U4TYhvXQTJlYidv1t4g1NcwxpvRk5C+xDd6UQSKnnB7xhF26MzUySqXZ7ijFfcTF//l0bkb2bdpl79jNhi7SVrRD38WRh/F13VMDpYTKEHUnbwzmKRkJP4zRFZ6xzitXr8eOv7XJ/lW/d6+wxUTl6PVB3EqE/N3dMpSYU/gw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jNKowJQ0mT0kSImfQFOpvtMIYJDgKfhc9ipmVmiEH7k=; b=iAjN1xbQ/MNDCKeyq9+aSz+uyuSDrf13bU3A4SyoDLtqHzWdCzeo6jTbOhqRKbMsTvyxSbfscFyAAIjgZf5P8TRdyRGWBs77iS+u/LphoqhAcsjIvHcrI+ecfxUJylX6soMzuqbHlgcTTuQjNYwXYiezcPyEqz9fggrJ8BoBLsD7xYDx7S3LMtc5VUROjg5sFLMhBzWMpGfL1mtA38hvf/sBj71gc5JBuxVNVERY7/Iy861XG8kIYzmeshZh45bbmfc8lZzc627ATmh7DoZp6Lef9qbV82SvQr7w+m2lR68xDkvsGqUTXZQ0YMONOfp8wOhmv/zX4qj2JVUGgszoUA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jNKowJQ0mT0kSImfQFOpvtMIYJDgKfhc9ipmVmiEH7k=; b=er+s485+2mrVEDwDQBbHcfQJ01CiWywMABlzKgSGMnz1y6f6OU3dZM8DvKFovmDN6OJ+SAX08iG7oEAGVqwNo/slIfmAJ7R/plU280Ahut1NRPwQXZlk+8P6ryKovGYJZzfUjma4lT8g5XtmK5qhJbpYanuykI4DM981QA3o/FU= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB2618.eurprd07.prod.outlook.com (10.168.186.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.15; Wed, 28 Aug 2019 16:33:46 +0000 Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::400c:cfd6:ee63:fb2f]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::400c:cfd6:ee63:fb2f%6]) with mapi id 15.20.2220.013; Wed, 28 Aug 2019 16:33:45 +0000 From: Mohit Sethi M To: Brian Rosen CC: "gen-art@ietf.org" , "draft-ietf-ecrit-data-only-ea.all@ietf.org" , "ietf@ietf.org" , "ecrit@ietf.org" Thread-Topic: Genart last call review of draft-ietf-ecrit-data-only-ea-18 Thread-Index: AQHVXbjJ7fiZrnKptkq6CV7wVVTXtKcQwUSA Date: Wed, 28 Aug 2019 16:33:45 +0000 Message-ID: <97271f7d-5430-957e-ffb3-cfa83cd3d915@ericsson.com> References: <156699952808.32349.1850578807441184126@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 Thunderbird/60.8.0 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; x-originating-ip: [176.93.86.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e18ccd38-5c62-459c-8dde-08d72bd57f1f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR0701MB2618; x-ms-traffictypediagnostic: HE1PR0701MB2618: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 014304E855 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(366004)(39860400002)(136003)(346002)(51444003)(189003)(199004)(476003)(256004)(99286004)(14444005)(5660300002)(2616005)(4326008)(25786009)(81166006)(81156014)(606006)(3846002)(6116002)(76176011)(6506007)(53936002)(53546011)(66066001)(8936002)(6246003)(65956001)(229853002)(7736002)(102836004)(64756008)(478600001)(66446008)(6916009)(8676002)(66946007)(26005)(6436002)(54906003)(66556008)(6486002)(186003)(66476007)(58126008)(71200400001)(71190400001)(446003)(6306002)(54896002)(2906002)(14454004)(486006)(316002)(76116006)(86362001)(236005)(31696002)(31686004)(36756003)(6512007)(11346002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2618; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: s7mZpiKay87VHfP71f0jJm42VonEH+pFQfZIuuYm+7zX4Rlpo57rnmAqFzMkWhXk1/tsP9MmMbUzVq3OmioO5y+QOXyNIXIMksj71e84IGjmH+X9tQvb3FHJBglhct1QVZt+qfR9nA9JyGOkYGeNq3SAfZa8nLi1a7QQjS+Ng2idKEzJCiwxTM8JqcwfmIEApuLNj5fU6YQrqwHP5u+MyMczdzyCIY9nTgyxgzpdqd6TM+sU64s8dwvSky9zELuUmvRa3IamFobxjRj4q2lZzXk61CmwfOgfIdRWkDBp9fQ25DfKAwc7oVg+FsJ2Ksw0/VPh1BJzPsWULCDza+gOGUrNMYz/RVUVrXk8oZVyEBYYF0pyVToZ/y0ZTF/NZF9WbAG1aw7Nts5uR5U8CpfDR5cgdhvnk49g4sskZ7vYCac= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_97271f7d5430957effb3cfa83cd3d915ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: e18ccd38-5c62-459c-8dde-08d72bd57f1f X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2019 16:33:45.5767 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: e/QizfzGqRyuv1sOfFsBLwKcLAivhHXNRbmYAFzQJ6bhXCQOEsPMIosgpTLnsPqUc+oJrW0H1Njcuvosz1vHoVVnwzdI2VQf2XF330ApR8s= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2618 Archived-At: Subject: Re: [Ecrit] Genart last call review of draft-ietf-ecrit-data-only-ea-18 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 16:33:55 -0000 --_000_97271f7d5430957effb3cfa83cd3d915ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4sDQoNClRoYW5rIHlvdSBmb3IgdGhlIGxpZ2h0ZW5pbmcgZmFzdCByZXNwb25zZS4N Cg0KSSB1bmRlcnN0YW5kIHRoYXQgcGlja2luZyB0aGUgY29ycmVjdCB3b3JkaW5nIGhlcmUgaXMg aGFyZC4gVGhhbmsgeW91IGZvciB0YWtpbmcgdGhpcyBkaXNjdXNzaW9uIGJhY2sgdG8gdGhlIHdv cmtpbmcgZ3JvdXAuIFdoYXRldmVyIHRoZSB3b3JraW5nIGdyb3VwIGV2ZW50dWFsbHkgZGVjaWRl cyBpcyBva2F5IGZvciBtZS4gQWx0aG91Z2ggSSBzdGlsbCB3b25kZXIgaWYgbm90aWZpY2F0aW9u LW9ubHkgZW1lcmdlbmN5IGNhbGwgaXMgc3VpdGFibGU/DQoNCkkga25vdyB0aGF0IGVtZXJnZW5j eSBjYWxscyBhcmUgYWNjZXB0ZWQgZnJvbSBhbnlvbmUsIGV2ZW4gZnJvbSBkZXZpY2VzIHRoYXQg ZG9uJ3QgaGF2ZSBhIFNJTSBjYXJkIGZvciBleGFtcGxlLiBXaGljaCBpcyB3aHkgSSB0aGluayB0 aGUgd29yZGluZyBzaG91bGQgYmUgImlzIGxpa2VseSB0byByZWNlaXZlIGFuZA0KYWNjZXB0IGFs ZXJ0cyBmcm9tIGVudGl0aWVzIGl0IGNhbm5vdCBhdXRoZW50aWNhdGUuIiBUaGVyZSBpcyBhIHJl ZmVyZW5jZSB0byBSRkMgNjg4MSBpbiB0aGUgZm9sbG93aW5nIHNlbnRlbmNlLiBJIGxvb2tlZCBh dCBSRkMgNjg4MSBicmllZmx5IGFuZCBpdCBvbmx5IHRhbGtzIGFib3V0IHVuYXV0aGVudGljYXRl ZCBkZXZpY2VzIGJ1dCBub3RoaW5nIGFib3V0IHVuYXV0aG9yaXplZCBkZXZpY2VzLiBJIHRoaW5r IHRoYXQgcmVjZWl2aW5nIGFsZXJ0cyBmcm9tIGRldmljZXMgd2hpY2ggYXJlIG5vdCBhdXRoZW50 aWNhdGVkIGNvdmVycyBhIGJyb2FkZXIgY2FzZSB0aGFuIGRldmljZXMgd2hpY2ggYXJlIGF1dGhl bnRpY2F0ZWQgYnV0IG5vdCBhdXRob3JpemVkLiBIb3dldmVyLCBJIGRvbid0IGhhdmUgZW5vdWdo IGNvbnRleHQgdG8gYmUgc3VyZSBhbmQgSSB0cnVzdCB5b3VyIGp1ZGdtZW50IG9uIHRoaXMuDQoN Ci0tTW9oaXQNCg0KT24gOC8yOC8xOSA2OjUzIFBNLCBCcmlhbiBSb3NlbiB3cm90ZToNCg0KVGhh bmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciByZXZpZXcuDQoNClRoZSB0ZXJtIHdlIHVzZSBmb3Ig dGhlc2Uga2luZHMgb2Yg4oCcY2FsbHPigJ0gaGFzIGNoYW5nZWQgc2V2ZXJhbCB0aW1lcy4gIFRo ZXJlIHJlYWxseSBpc27igJl0IGEgZ3JlYXQgbmFtZS4NCkluIGFub3RoZXIgZm9ydW0sIHdl4oCZ cmUgY2FsbGluZyB0aGVtIOKAnG5vbi1odW1hbi1pbml0aWF0ZWTigJ0sIGJ1dCB0aGF0IHJlYWxs eSBpc27igJl0IHJpZ2h0IGVpdGhlci4gIElmIHlvdSBwcmVzcyBhIGJ1dHRvbiBhbmQgYSBkZXZp Y2Ugc2VuZHMgeW91ciBsb2NhdGlvbiBhbmQgc29tZSBtZWRpY2FsIGRhdGEsIHRoZW4gaXQgSVMg aHVtYW4gaW5pdGlhdGVkLg0KDQpUaGUgZGlmZmVyZW50aWF0aW9uIHRoYXQgbWF0dGVycyBpcyB3 aGV0aGVyIHRoZXJlIGlzIHR3byB3YXkgaW50ZXJhY3RpdmUgbWVkaWEgb3Igbm90LCB3aGljaCBh bHNvIG1lYW5zIHdoZXRoZXIgdGhlcmUgaXMgYSBzZXNzaW9uIG9yIG5vdC4NCk1vc3Qgb2YgdGhl c2Ug4oCcY2FsbHPigJ0gd2lsbCBiZSBmcm9tIHNlbnNvcnMsIGFuZCByZWFsbHkgYXJlIGRhdGEt b25seSwgYW5kIEkgdGhpbmsgdGhlIGRpZmZlcmVudGlhdGlvbiBiZXR3ZWVuIGRhdGEgYW5kIG1l ZGlhIGlzIGNsZWFyIGFuZCBub3QgY29uZnVzaW5nLiAgQnV0IHlvdSBjb3VsZCBoYXZlIG9uZSB3 YXksIG5vbiBpbnRlcmFjdGl2ZSBtZWRpYSBzaWduYWxlZCB3aXRoIHRoZXNlIGNhbGxzIChhIHN1 cnZlaWxsYW5jZSBjYW1lcmEgZm9yIGV4YW1wbGUpLiAgVGhlIGNhbGwgd291bGQgYmUgc2Vzc2lv bi1sZXNzLiAgVGhlIGNhbWVyYSBpbmZvcm1hdGlvbiB3b3VsZCBiZSBwYXNzZWQgYXMgYSBVUkkg dG8gYW4gUlRTUCBtZWRpYSBzdHJlYW0sIHNvIHdoYXQgaXMgcGFzc2VkIHJlYWxseSBpcyBkYXRh ICh0aGUgVVJMKSBhbmQgbm90IHRoZSBtZWRpYSwgYnV0IHRoZXJlIElTIG1lZGlhIGludm9sdmVk LCBzbyDigJxkYXRhLW9ubHnigJ0gaXNu4oCZdCBncmVhdC4NCg0K4oCcTm9uIEludGVyYWN0aXZl 4oCdIG1heSBhbHNvIG5vdCBiZSBxdWl0ZSByaWdodDogSWYgYW4gZWxldmF0b3Igc2VuZHMgeW91 IGFuIGFsZXJ0IGFuZCBhbHNvIGdpdmVzIHJlc3BvbmRlcnMgYWNjZXNzIHRvIGNvbnRyb2wgaXQs IGlzIHRoYXQgaW50ZXJhY3RpdmU/ICBUaGUg4oCcY2FsbOKAnSBpc27igJl0LCBidXQgdGhlIG5h bWUgY291bGQgYmUgbWlzbGVhZGluZy4NCg0KSW4gdGhlIGVuZCwgSSBkb27igJl0IHRoaW5rIGNo YW5naW5nIHRoZSBuYW1lIGlzIHdvcnRoIHdoaWxlLiAgSXTigJlzIGZhaXJseSBhY2N1cmF0ZSwg bm90IGNvbmZ1c2luZy4gIEnigJlkIGJlIG9rYXkgd2l0aCBjaGFuZ2luZyBpdCB0byDigJxOb24t SHVtYW4tSW5pdGlhdGVk4oCdLCBidXQgdGhhdCBoYXMgcHJvYmxlbXMgYWxzby4gIEkgd2lsbCB0 YWtlIHRoaXMgZGlzY3Vzc2lvbiBiYWNrIHRvIHRoZSB3b3JrIGdyb3VwIHRob3VnaCwNCg0K4oCc QXV0aG9yaXpl4oCdIHJlYWxseSBpcyB0aGUgcmlnaHQgd29yZC4gIFdlIG1heSBiZSBhYmxlIHRv IGF1dGhlbnRpY2F0ZSB5b3UgKHVzaW5nIHN0aXIgZm9yIGV4YW1wbGUpLCBidXQgd2UgdXN1YWxs eSBkb27igJl0IGhhdmUgYW55IGF1dGhvcml6YXRpb24gbWVjaGFuaXNtIC0gdW5sZXNzIHdl4oCZ cmUgdW5kZXIgYXR0YWNrLCB3ZSB0YWtlIGNhbGxzIGZyb20gYW55b25lLiAgVGhhdOKAmXMgdGhl IG5hdHVyZSBvZiBlbWVyZ2VuY3kgY2FsbHMuICBJbiB0aGUgVVMsIHlvdSBjYW4gZ2V0IGFuIGVt ZXJnZW5jeSBjYWxsIGZyb20gYSBtb2JpbGUgdGhhdCBoYXMgbm8gc2VydmljZS4NCg0KSeKAmWxs IGRvIHRoZSBlZGl0cyBmb3IgdGhlIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gaW4gdGhlIHBhcmFt ZXRlci4gIFBJREYtTE8gaXMgaG93IGVtZXJnZW5jeSBjYWxscyBzZW5kIGxvY2F0aW9uLiAgSeKA mWxsIGltcHJvdmUgdGhhdCB0ZXh0LiAgQWxzbyB3aWxsIHN1YnN0aXR1dGUg4oCcZGV0ZWN0c+KA nSBmb3Ig4oCcdW5kZXJzdGFuZHPigJ0gYW5kIGZpeCB0aGUgbml0cy4NCg0KDQpCcmlhbg0KDQoN Cg0KDQpPbiBBdWcgMjgsIDIwMTksIGF0IDk6MzggQU0sIE1vaGl0IFNldGhpIHZpYSBEYXRhdHJh Y2tlciA8bm9yZXBseUBpZXRmLm9yZz48bWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0K DQpSZXZpZXdlcjogTW9oaXQgU2V0aGkNClJldmlldyByZXN1bHQ6IFJlYWR5IHdpdGggSXNzdWVz DQoNCkkgYW0gdGhlIGFzc2lnbmVkIEdlbi1BUlQgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRo ZSBHZW5lcmFsIEFyZWENClJldmlldyBUZWFtIChHZW4tQVJUKSByZXZpZXdzIGFsbCBJRVRGIGRv Y3VtZW50cyBiZWluZyBwcm9jZXNzZWQNCmJ5IHRoZSBJRVNHIGZvciB0aGUgSUVURiBDaGFpci4g IFBsZWFzZSB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0DQpsaWtlIGFueSBvdGhlciBsYXN0IGNh bGwgY29tbWVudHMuDQoNCkZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBGQVEg YXQNCg0KPGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2dlbi93aWtpL0dlbkFydGZhcT48aHR0 cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvZ2VuL3dpa2kvR2VuQXJ0ZmFxPi4NCg0KRG9jdW1lbnQ6 IGRyYWZ0LWlldGYtZWNyaXQtZGF0YS1vbmx5LWVhLTE4DQpSZXZpZXdlcjogTW9oaXQgU2V0aGkN ClJldmlldyBEYXRlOiAyMDE5LTA4LTI4DQpJRVRGIExDIEVuZCBEYXRlOiAyMDE5LTA5LTAyDQpJ RVNHIFRlbGVjaGF0IGRhdGU6IE5vdCBzY2hlZHVsZWQgZm9yIGEgdGVsZWNoYXQNCg0KU3VtbWFy eTogVGhpcyBkcmFmdCBpcyBhbG1vc3QgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLCBidXQgaGFzIHNv bWUgaXNzdWVzIHRoYXQNCmNvbmNlcm4gbWUuIFRoZSBtb3N0IGltcG9ydGFudCBvbmUgaXMgdGhl IGNob2ljZSBvZiB0aGUgdGVybSAiZGF0YS1vbmx5Ii4NCg0KTWFqb3IgaXNzdWVzOiBJIGFtIHVu c3VyZSB3aHkgdGhlIGF1dGhvcnMgYW5kIHRoZSBXRyBjaG9zZSB0aGUgdGVybSBkYXRhLW9ubHkN CmVtZXJnZW5jeSBjYWxsPyBGaXJzdCwgSSB0aG91Z2h0IHRoYXQgaXQgaXMgcmVmZXJyaW5nIHRv IGEgdW5pZGlyZWN0aW9uYWwgY2FsbA0KYnV0IHRoYXQgaXNuJ3QgdGhlIGNhc2UgaGVyZS4gQWxz bywgYXJlbid0IGludGVyYWN0aXZlIFJUUCBzZXNzaW9ucyBhbHNvDQplc3NlbnRpYWxseSBjb21w b3NlZCBvZiBkYXRhIHBhY2tldHM/DQoNClBlcmhhcHMgbm90aWZpY2F0aW9uLW9ubHkgYW5kL29y IG5vbi1pbnRlcmF0aXZlIGVtZXJnZW5jeSBjYWxscyBjb3VsZCBiZQ0KY29uc2lkZXJlZCBhcyBh biBhbHRlcm5hdGl2ZS4NCg0KTWlub3IgaXNzdWVzOiBUaGUgdGV4dCBzYXlzICJBIFBTQVAsIGZv ciBleGFtcGxlLCBpcyBsaWtlbHkgdG8gcmVjZWl2ZSBhbmQNCmFjY2VwdCBhbGVydHMgZnJvbSBl bnRpdGllcyBpdCBjYW5ub3QgYXV0aG9yaXplLiIuIElzIGF1dGhvcml6ZSB0aGUgY29ycmVjdA0K d29yZD8gZGlkIHlvdSBtZWFuIGF1dGhlbnRpY2F0ZT8gWW91IG5lZWQgdG8gYXV0aGVudGljYXRl IGJlZm9yZSB5b3UgYXV0aG9yaXplLg0KDQpwYXJhbWV0ZXI6IE1BWSBjb250YWluIGFkZGl0aW9u YWwgaW5mb3JtYXRpb24uIElzIGl0IEFTQ0lJPyBIb3cgbG9uZyBjYW4gaXQgYmU/DQpJIHByZXN1 bWUgdGhhdCB0aGUgQ0FQIGhhcyBzb21lIGNsZWFybGVyIGd1aWRlbGluZS4gQXQgbGVhc3QgeW91 IGNvdWxkIHdyaXRlDQp0aGF0IHRoZSBDQVAgcmVzdHJpY3Rpb25zIGFwcGx5DQoNClRoZSB0ZXh0 IHNheXMgc29tZXRoaW5nIGFib3V0IFBJREYtTE8gc3RydWN0dXJlIHJlZmVyZW5jZWQgYnk/IEkg YW0gbm90IHN1cmUNCndoYXQgaXMgbWVhbnQgaGVyZT8gUGVyaGFwcyBzb21lIG1vcmUgdGV4dCBo ZXJlIHdvdWxkIGhlbHAgdGhlIHJlYWRlcg0KdW5kZXJzdGFuZCBiZXR0ZXIuDQoNClRoZSB0ZXh0 IHNheXMgIkEgU0lQIGludGVybWVkaWFyeSBjYW4gYWxzbyByZWplY3QgYW4gYWxlcnQgaXQgcmVj ZWl2ZXMgZnJvbSBhDQpVc2VyIEFnZW50IChVQSkgd2hlbiBpdCB1bmRlcnN0YW5kcyB0aGF0IHRo ZSBwcm92aWRlZCBhbGVydCBpcyBtYWxmb3JtZWQuIi4NClBlcmhhcHMgZGV0ZWN0cyBpcyBiZXR0 ZXIgY2hvaWNlIHRoYW4gdW5kZXJzdGFuZC4gSXQgY2Fubm90IHVuZGVyc3RhbmQNCnNvbWV0aGlu ZyB0aGF0IGlzIG1hbGZvcm1lZC4NCg0KTml0cy9lZGl0b3JpYWwgY29tbWVudHM6DQoNCmNpdGl6 ZW4vaW5kaXZpZHVhbCAtPiBjaXRpemVucy9pbmRpdmlkdWFscw0KU2VuZGluZyBhIG5vbi1pbnRl cmFjdGl2ZSBjYWxsIGNvbnRhaW5pbmcgb25seSBkYXRhIHRvd2FyZCBhIC0+IG9ubHkgZGF0YQ0K dG93YXJkcyBhIEZpZ3VyZXMgMSBhbmQgMiBjb3VsZCBoYXZlIG1vcmUgaW5mby4gSXMgaXQgYSBI VFRQIG9yIFNJUCAyMDAgKE9LKT8NCmFuZCB0aGUgcmVjaXBpZW50IHVzaW5nIEhUVFBTIHRvIHJl dHJpZXZlIHRoZSBkYXRhLiAgLT4gYW5kIHRoZSByZWNpcGllbnQgdXNlcw0KSFRUUFMgdG8gcmV0 cmlldmUgdGhlIGRhdGEuDQoNCg0KDQoNCg0K --_000_97271f7d5430957effb3cfa83cd3d915ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <1D29C38EFEBA644684A0C2D45D59C996@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IiNGRkZG RkYiIHRleHQ9IiMwMDAwMDAiPg0KPHA+SGkgQnJpYW4sPC9wPg0KPHA+VGhhbmsgeW91IGZvciB0 aGUgbGlnaHRlbmluZyBmYXN0IHJlc3BvbnNlLiA8YnI+DQo8L3A+DQo8cD5JIHVuZGVyc3RhbmQg dGhhdCBwaWNraW5nIHRoZSBjb3JyZWN0IHdvcmRpbmcgaGVyZSBpcyBoYXJkLiBUaGFuayB5b3Ug Zm9yIHRha2luZyB0aGlzIGRpc2N1c3Npb24gYmFjayB0byB0aGUgd29ya2luZyBncm91cC4gV2hh dGV2ZXIgdGhlIHdvcmtpbmcgZ3JvdXAgZXZlbnR1YWxseSBkZWNpZGVzIGlzIG9rYXkgZm9yIG1l LiBBbHRob3VnaCBJIHN0aWxsIHdvbmRlciBpZg0KPGI+bm90aWZpY2F0aW9uLW9ubHkgZW1lcmdl bmN5IGNhbGw8L2I+IGlzIHN1aXRhYmxlPyA8YnI+DQo8L3A+DQo8cD5JIGtub3cgdGhhdCBlbWVy Z2VuY3kgY2FsbHMgYXJlIGFjY2VwdGVkIGZyb20gYW55b25lLCBldmVuIGZyb20gZGV2aWNlcyB0 aGF0IGRvbid0IGhhdmUgYSBTSU0gY2FyZCBmb3IgZXhhbXBsZS4gV2hpY2ggaXMgd2h5IEkgdGhp bmsgdGhlIHdvcmRpbmcgc2hvdWxkIGJlICZxdW90O2lzIGxpa2VseSB0byByZWNlaXZlIGFuZDxi cj4NCmFjY2VwdCBhbGVydHMgZnJvbSBlbnRpdGllcyBpdCBjYW5ub3QgYXV0aGVudGljYXRlLiZx dW90OyBUaGVyZSBpcyBhIHJlZmVyZW5jZSB0byBSRkMgNjg4MSBpbiB0aGUgZm9sbG93aW5nIHNl bnRlbmNlLiBJIGxvb2tlZCBhdCBSRkMgNjg4MSBicmllZmx5IGFuZCBpdCBvbmx5IHRhbGtzIGFi b3V0IHVuYXV0aGVudGljYXRlZCBkZXZpY2VzIGJ1dCBub3RoaW5nIGFib3V0IHVuYXV0aG9yaXpl ZCBkZXZpY2VzLiBJIHRoaW5rIHRoYXQgcmVjZWl2aW5nIGFsZXJ0cw0KIGZyb20gZGV2aWNlcyB3 aGljaCBhcmUgbm90IGF1dGhlbnRpY2F0ZWQgY292ZXJzIGEgYnJvYWRlciBjYXNlIHRoYW4gZGV2 aWNlcyB3aGljaCBhcmUgYXV0aGVudGljYXRlZCBidXQgbm90IGF1dGhvcml6ZWQuIEhvd2V2ZXIs IEkgZG9uJ3QgaGF2ZSBlbm91Z2ggY29udGV4dCB0byBiZSBzdXJlIGFuZCBJIHRydXN0IHlvdXIg anVkZ21lbnQgb24gdGhpcy4NCjwvcD4NCjxwPi0tTW9oaXQ8YnI+DQo8L3A+DQo8ZGl2IGNsYXNz PSJtb3otY2l0ZS1wcmVmaXgiPk9uIDgvMjgvMTkgNjo1MyBQTSwgQnJpYW4gUm9zZW4gd3JvdGU6 PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJtaWQ6QjAyREIzNjYt QjVGQy00ODE2LThBOEQtMzg2MjA2ODg4NUU4QGJyaWFucm9zZW4ubmV0Ij4NCjxwcmUgY2xhc3M9 Im1vei1xdW90ZS1wcmUiIHdyYXA9IiI+VGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciByZXZp ZXcuDQoNClRoZSB0ZXJtIHdlIHVzZSBmb3IgdGhlc2Uga2luZHMgb2Yg4oCcY2FsbHPigJ0gaGFz IGNoYW5nZWQgc2V2ZXJhbCB0aW1lcy4gIFRoZXJlIHJlYWxseSBpc27igJl0IGEgZ3JlYXQgbmFt ZS4NCkluIGFub3RoZXIgZm9ydW0sIHdl4oCZcmUgY2FsbGluZyB0aGVtIOKAnG5vbi1odW1hbi1p bml0aWF0ZWTigJ0sIGJ1dCB0aGF0IHJlYWxseSBpc27igJl0IHJpZ2h0IGVpdGhlci4gIElmIHlv dSBwcmVzcyBhIGJ1dHRvbiBhbmQgYSBkZXZpY2Ugc2VuZHMgeW91ciBsb2NhdGlvbiBhbmQgc29t ZSBtZWRpY2FsIGRhdGEsIHRoZW4gaXQgSVMgaHVtYW4gaW5pdGlhdGVkLg0KDQpUaGUgZGlmZmVy ZW50aWF0aW9uIHRoYXQgbWF0dGVycyBpcyB3aGV0aGVyIHRoZXJlIGlzIHR3byB3YXkgaW50ZXJh Y3RpdmUgbWVkaWEgb3Igbm90LCB3aGljaCBhbHNvIG1lYW5zIHdoZXRoZXIgdGhlcmUgaXMgYSBz ZXNzaW9uIG9yIG5vdC4gDQpNb3N0IG9mIHRoZXNlIOKAnGNhbGxz4oCdIHdpbGwgYmUgZnJvbSBz ZW5zb3JzLCBhbmQgcmVhbGx5IGFyZSBkYXRhLW9ubHksIGFuZCBJIHRoaW5rIHRoZSBkaWZmZXJl bnRpYXRpb24gYmV0d2VlbiBkYXRhIGFuZCBtZWRpYSBpcyBjbGVhciBhbmQgbm90IGNvbmZ1c2lu Zy4gIEJ1dCB5b3UgY291bGQgaGF2ZSBvbmUgd2F5LCBub24gaW50ZXJhY3RpdmUgbWVkaWEgc2ln bmFsZWQgd2l0aCB0aGVzZSBjYWxscyAoYSBzdXJ2ZWlsbGFuY2UgY2FtZXJhIGZvciBleGFtcGxl KS4gIFRoZSBjYWxsIHdvdWxkIGJlIHNlc3Npb24tbGVzcy4gIFRoZSBjYW1lcmEgaW5mb3JtYXRp b24gd291bGQgYmUgcGFzc2VkIGFzIGEgVVJJIHRvIGFuIFJUU1AgbWVkaWEgc3RyZWFtLCBzbyB3 aGF0IGlzIHBhc3NlZCByZWFsbHkgaXMgZGF0YSAodGhlIFVSTCkgYW5kIG5vdCB0aGUgbWVkaWEs IGJ1dCB0aGVyZSBJUyBtZWRpYSBpbnZvbHZlZCwgc28g4oCcZGF0YS1vbmx54oCdIGlzbuKAmXQg Z3JlYXQuDQoNCuKAnE5vbiBJbnRlcmFjdGl2ZeKAnSBtYXkgYWxzbyBub3QgYmUgcXVpdGUgcmln aHQ6IElmIGFuIGVsZXZhdG9yIHNlbmRzIHlvdSBhbiBhbGVydCBhbmQgYWxzbyBnaXZlcyByZXNw b25kZXJzIGFjY2VzcyB0byBjb250cm9sIGl0LCBpcyB0aGF0IGludGVyYWN0aXZlPyAgVGhlIOKA nGNhbGzigJ0gaXNu4oCZdCwgYnV0IHRoZSBuYW1lIGNvdWxkIGJlIG1pc2xlYWRpbmcuDQoNCklu IHRoZSBlbmQsIEkgZG9u4oCZdCB0aGluayBjaGFuZ2luZyB0aGUgbmFtZSBpcyB3b3J0aCB3aGls ZS4gIEl04oCZcyBmYWlybHkgYWNjdXJhdGUsIG5vdCBjb25mdXNpbmcuICBJ4oCZZCBiZSBva2F5 IHdpdGggY2hhbmdpbmcgaXQgdG8g4oCcTm9uLUh1bWFuLUluaXRpYXRlZOKAnSwgYnV0IHRoYXQg aGFzIHByb2JsZW1zIGFsc28uICBJIHdpbGwgdGFrZSB0aGlzIGRpc2N1c3Npb24gYmFjayB0byB0 aGUgd29yayBncm91cCB0aG91Z2gsDQoNCuKAnEF1dGhvcml6ZeKAnSByZWFsbHkgaXMgdGhlIHJp Z2h0IHdvcmQuICBXZSBtYXkgYmUgYWJsZSB0byBhdXRoZW50aWNhdGUgeW91ICh1c2luZyBzdGly IGZvciBleGFtcGxlKSwgYnV0IHdlIHVzdWFsbHkgZG9u4oCZdCBoYXZlIGFueSBhdXRob3JpemF0 aW9uIG1lY2hhbmlzbSAtIHVubGVzcyB3ZeKAmXJlIHVuZGVyIGF0dGFjaywgd2UgdGFrZSBjYWxs cyBmcm9tIGFueW9uZS4gIFRoYXTigJlzIHRoZSBuYXR1cmUgb2YgZW1lcmdlbmN5IGNhbGxzLiAg SW4gdGhlIFVTLCB5b3UgY2FuIGdldCBhbiBlbWVyZ2VuY3kgY2FsbCBmcm9tIGEgbW9iaWxlIHRo YXQgaGFzIG5vIHNlcnZpY2UuDQoNCknigJlsbCBkbyB0aGUgZWRpdHMgZm9yIHRoZSBhZGRpdGlv bmFsIGluZm9ybWF0aW9uIGluIHRoZSBwYXJhbWV0ZXIuICBQSURGLUxPIGlzIGhvdyBlbWVyZ2Vu Y3kgY2FsbHMgc2VuZCBsb2NhdGlvbi4gIEnigJlsbCBpbXByb3ZlIHRoYXQgdGV4dC4gIEFsc28g d2lsbCBzdWJzdGl0dXRlIOKAnGRldGVjdHPigJ0gZm9yIOKAnHVuZGVyc3RhbmRz4oCdIGFuZCBm aXggdGhlIG5pdHMuDQoNCg0KQnJpYW4NCg0KDQo8L3ByZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPg0KPHByZSBjbGFzcz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj5PbiBBdWcgMjgsIDIwMTks IGF0IDk6MzggQU0sIE1vaGl0IFNldGhpIHZpYSBEYXRhdHJhY2tlciA8YSBjbGFzcz0ibW96LXR4 dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86bm9yZXBseUBpZXRmLm9yZyI+Jmx0O25vcmVw bHlAaWV0Zi5vcmcmZ3Q7PC9hPiB3cm90ZToNCg0KUmV2aWV3ZXI6IE1vaGl0IFNldGhpDQpSZXZp ZXcgcmVzdWx0OiBSZWFkeSB3aXRoIElzc3Vlcw0KDQpJIGFtIHRoZSBhc3NpZ25lZCBHZW4tQVJU IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgR2VuZXJhbCBBcmVhDQpSZXZpZXcgVGVhbSAo R2VuLUFSVCkgcmV2aWV3cyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkDQpieSB0 aGUgSUVTRyBmb3IgdGhlIElFVEYgQ2hhaXIuICBQbGVhc2UgdHJlYXQgdGhlc2UgY29tbWVudHMg anVzdA0KbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpGb3IgbW9yZSBpbmZv cm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgRkFRIGF0DQoNCjxhIGNsYXNzPSJtb3otdHh0LWxpbmst cmZjMjM5NkUiIGhyZWY9Imh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2dlbi93aWtpL0dlbkFy dGZhcSI+Jmx0O2h0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2dlbi93aWtpL0dlbkFydGZhcSZn dDs8L2E+Lg0KDQpEb2N1bWVudDogZHJhZnQtaWV0Zi1lY3JpdC1kYXRhLW9ubHktZWEtMTgNClJl dmlld2VyOiBNb2hpdCBTZXRoaQ0KUmV2aWV3IERhdGU6IDIwMTktMDgtMjgNCklFVEYgTEMgRW5k IERhdGU6IDIwMTktMDktMDINCklFU0cgVGVsZWNoYXQgZGF0ZTogTm90IHNjaGVkdWxlZCBmb3Ig YSB0ZWxlY2hhdA0KDQpTdW1tYXJ5OiBUaGlzIGRyYWZ0IGlzIGFsbW9zdCByZWFkeSBmb3IgcHVi bGljYXRpb24sIGJ1dCBoYXMgc29tZSBpc3N1ZXMgdGhhdA0KY29uY2VybiBtZS4gVGhlIG1vc3Qg aW1wb3J0YW50IG9uZSBpcyB0aGUgY2hvaWNlIG9mIHRoZSB0ZXJtICZxdW90O2RhdGEtb25seSZx dW90Oy4NCg0KTWFqb3IgaXNzdWVzOiBJIGFtIHVuc3VyZSB3aHkgdGhlIGF1dGhvcnMgYW5kIHRo ZSBXRyBjaG9zZSB0aGUgdGVybSBkYXRhLW9ubHkNCmVtZXJnZW5jeSBjYWxsPyBGaXJzdCwgSSB0 aG91Z2h0IHRoYXQgaXQgaXMgcmVmZXJyaW5nIHRvIGEgdW5pZGlyZWN0aW9uYWwgY2FsbA0KYnV0 IHRoYXQgaXNuJ3QgdGhlIGNhc2UgaGVyZS4gQWxzbywgYXJlbid0IGludGVyYWN0aXZlIFJUUCBz ZXNzaW9ucyBhbHNvDQplc3NlbnRpYWxseSBjb21wb3NlZCBvZiBkYXRhIHBhY2tldHM/DQoNClBl cmhhcHMgbm90aWZpY2F0aW9uLW9ubHkgYW5kL29yIG5vbi1pbnRlcmF0aXZlIGVtZXJnZW5jeSBj YWxscyBjb3VsZCBiZQ0KY29uc2lkZXJlZCBhcyBhbiBhbHRlcm5hdGl2ZS4NCg0KTWlub3IgaXNz dWVzOiBUaGUgdGV4dCBzYXlzICZxdW90O0EgUFNBUCwgZm9yIGV4YW1wbGUsIGlzIGxpa2VseSB0 byByZWNlaXZlIGFuZA0KYWNjZXB0IGFsZXJ0cyBmcm9tIGVudGl0aWVzIGl0IGNhbm5vdCBhdXRo b3JpemUuJnF1b3Q7LiBJcyBhdXRob3JpemUgdGhlIGNvcnJlY3QNCndvcmQ/IGRpZCB5b3UgbWVh biBhdXRoZW50aWNhdGU/IFlvdSBuZWVkIHRvIGF1dGhlbnRpY2F0ZSBiZWZvcmUgeW91IGF1dGhv cml6ZS4NCg0KcGFyYW1ldGVyOiBNQVkgY29udGFpbiBhZGRpdGlvbmFsIGluZm9ybWF0aW9uLiBJ cyBpdCBBU0NJST8gSG93IGxvbmcgY2FuIGl0IGJlPw0KSSBwcmVzdW1lIHRoYXQgdGhlIENBUCBo YXMgc29tZSBjbGVhcmxlciBndWlkZWxpbmUuIEF0IGxlYXN0IHlvdSBjb3VsZCB3cml0ZQ0KdGhh dCB0aGUgQ0FQIHJlc3RyaWN0aW9ucyBhcHBseQ0KDQpUaGUgdGV4dCBzYXlzIHNvbWV0aGluZyBh Ym91dCBQSURGLUxPIHN0cnVjdHVyZSByZWZlcmVuY2VkIGJ5PyBJIGFtIG5vdCBzdXJlDQp3aGF0 IGlzIG1lYW50IGhlcmU/IFBlcmhhcHMgc29tZSBtb3JlIHRleHQgaGVyZSB3b3VsZCBoZWxwIHRo ZSByZWFkZXINCnVuZGVyc3RhbmQgYmV0dGVyLg0KDQpUaGUgdGV4dCBzYXlzICZxdW90O0EgU0lQ IGludGVybWVkaWFyeSBjYW4gYWxzbyByZWplY3QgYW4gYWxlcnQgaXQgcmVjZWl2ZXMgZnJvbSBh DQpVc2VyIEFnZW50IChVQSkgd2hlbiBpdCB1bmRlcnN0YW5kcyB0aGF0IHRoZSBwcm92aWRlZCBh bGVydCBpcyBtYWxmb3JtZWQuJnF1b3Q7Lg0KUGVyaGFwcyBkZXRlY3RzIGlzIGJldHRlciBjaG9p Y2UgdGhhbiB1bmRlcnN0YW5kLiBJdCBjYW5ub3QgdW5kZXJzdGFuZA0Kc29tZXRoaW5nIHRoYXQg aXMgbWFsZm9ybWVkLg0KDQpOaXRzL2VkaXRvcmlhbCBjb21tZW50czoNCg0KY2l0aXplbi9pbmRp dmlkdWFsIC0mZ3Q7IGNpdGl6ZW5zL2luZGl2aWR1YWxzDQpTZW5kaW5nIGEgbm9uLWludGVyYWN0 aXZlIGNhbGwgY29udGFpbmluZyBvbmx5IGRhdGEgdG93YXJkIGEgLSZndDsgb25seSBkYXRhDQp0 b3dhcmRzIGEgRmlndXJlcyAxIGFuZCAyIGNvdWxkIGhhdmUgbW9yZSBpbmZvLiBJcyBpdCBhIEhU VFAgb3IgU0lQIDIwMCAoT0spPw0KYW5kIHRoZSByZWNpcGllbnQgdXNpbmcgSFRUUFMgdG8gcmV0 cmlldmUgdGhlIGRhdGEuICAtJmd0OyBhbmQgdGhlIHJlY2lwaWVudCB1c2VzDQpIVFRQUyB0byBy ZXRyaWV2ZSB0aGUgZGF0YS4NCg0KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlIGNsYXNzPSJt b3otcXVvdGUtcHJlIiB3cmFwPSIiPg0KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_97271f7d5430957effb3cfa83cd3d915ericssoncom_-- From nobody Wed Aug 28 09:34:16 2019 Return-Path: X-Original-To: expand-draft-ietf-ecrit-data-only-ea.all@virtual.ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8CA501200B2; Wed, 28 Aug 2019 09:33:55 -0700 (PDT) X-Original-To: xfilter-draft-ietf-ecrit-data-only-ea.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-ecrit-data-only-ea.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C0912018D; Wed, 28 Aug 2019 09:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 I1Cm8wDcdbbG; Wed, 28 Aug 2019 09:33:51 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00061.outbound.protection.outlook.com [40.107.0.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F0E91200B2; Wed, 28 Aug 2019 09:33:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BF93glTUz3G/t8kg7grXIdefqdgtaz9U5LWuOwgFXcshkUf1+IVIfPVXuzr4lNGWbgWXfphloKjL0uc+c57I4ISjbdZmEVYXrFVawl/p8Pu0NJpdNxMi6FgGvGnO5FBfNYRicE9FeBO7ib6joNRrhXjXqp1GEWf9zm6E5DGZRheP71U4TYhvXQTJlYidv1t4g1NcwxpvRk5C+xDd6UQSKnnB7xhF26MzUySqXZ7ijFfcTF//l0bkb2bdpl79jNhi7SVrRD38WRh/F13VMDpYTKEHUnbwzmKRkJP4zRFZ6xzitXr8eOv7XJ/lW/d6+wxUTl6PVB3EqE/N3dMpSYU/gw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jNKowJQ0mT0kSImfQFOpvtMIYJDgKfhc9ipmVmiEH7k=; b=iAjN1xbQ/MNDCKeyq9+aSz+uyuSDrf13bU3A4SyoDLtqHzWdCzeo6jTbOhqRKbMsTvyxSbfscFyAAIjgZf5P8TRdyRGWBs77iS+u/LphoqhAcsjIvHcrI+ecfxUJylX6soMzuqbHlgcTTuQjNYwXYiezcPyEqz9fggrJ8BoBLsD7xYDx7S3LMtc5VUROjg5sFLMhBzWMpGfL1mtA38hvf/sBj71gc5JBuxVNVERY7/Iy861XG8kIYzmeshZh45bbmfc8lZzc627ATmh7DoZp6Lef9qbV82SvQr7w+m2lR68xDkvsGqUTXZQ0YMONOfp8wOhmv/zX4qj2JVUGgszoUA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jNKowJQ0mT0kSImfQFOpvtMIYJDgKfhc9ipmVmiEH7k=; b=er+s485+2mrVEDwDQBbHcfQJ01CiWywMABlzKgSGMnz1y6f6OU3dZM8DvKFovmDN6OJ+SAX08iG7oEAGVqwNo/slIfmAJ7R/plU280Ahut1NRPwQXZlk+8P6ryKovGYJZzfUjma4lT8g5XtmK5qhJbpYanuykI4DM981QA3o/FU= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB2618.eurprd07.prod.outlook.com (10.168.186.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.15; Wed, 28 Aug 2019 16:33:46 +0000 Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::400c:cfd6:ee63:fb2f]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::400c:cfd6:ee63:fb2f%6]) with mapi id 15.20.2220.013; Wed, 28 Aug 2019 16:33:45 +0000 From: Mohit Sethi M To: Brian Rosen CC: "gen-art@ietf.org" , "draft-ietf-ecrit-data-only-ea.all@ietf.org" , "ietf@ietf.org" , "ecrit@ietf.org" Thread-Topic: Genart last call review of draft-ietf-ecrit-data-only-ea-18 Thread-Index: AQHVXbjJ7fiZrnKptkq6CV7wVVTXtKcQwUSA Date: Wed, 28 Aug 2019 16:33:45 +0000 Message-ID: <97271f7d-5430-957e-ffb3-cfa83cd3d915@ericsson.com> References: <156699952808.32349.1850578807441184126@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 Thunderbird/60.8.0 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; x-originating-ip: [176.93.86.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e18ccd38-5c62-459c-8dde-08d72bd57f1f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR0701MB2618; x-ms-traffictypediagnostic: HE1PR0701MB2618: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 014304E855 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(366004)(39860400002)(136003)(346002)(51444003)(189003)(199004)(476003)(256004)(99286004)(14444005)(5660300002)(2616005)(4326008)(25786009)(81166006)(81156014)(606006)(3846002)(6116002)(76176011)(6506007)(53936002)(53546011)(66066001)(8936002)(6246003)(65956001)(229853002)(7736002)(102836004)(64756008)(478600001)(66446008)(6916009)(8676002)(66946007)(26005)(6436002)(54906003)(66556008)(6486002)(186003)(66476007)(58126008)(71200400001)(71190400001)(446003)(6306002)(54896002)(2906002)(14454004)(486006)(316002)(76116006)(86362001)(236005)(31696002)(31686004)(36756003)(6512007)(11346002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2618; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: s7mZpiKay87VHfP71f0jJm42VonEH+pFQfZIuuYm+7zX4Rlpo57rnmAqFzMkWhXk1/tsP9MmMbUzVq3OmioO5y+QOXyNIXIMksj71e84IGjmH+X9tQvb3FHJBglhct1QVZt+qfR9nA9JyGOkYGeNq3SAfZa8nLi1a7QQjS+Ng2idKEzJCiwxTM8JqcwfmIEApuLNj5fU6YQrqwHP5u+MyMczdzyCIY9nTgyxgzpdqd6TM+sU64s8dwvSky9zELuUmvRa3IamFobxjRj4q2lZzXk61CmwfOgfIdRWkDBp9fQ25DfKAwc7oVg+FsJ2Ksw0/VPh1BJzPsWULCDza+gOGUrNMYz/RVUVrXk8oZVyEBYYF0pyVToZ/y0ZTF/NZF9WbAG1aw7Nts5uR5U8CpfDR5cgdhvnk49g4sskZ7vYCac= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_97271f7d5430957effb3cfa83cd3d915ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: e18ccd38-5c62-459c-8dde-08d72bd57f1f X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2019 16:33:45.5767 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: e/QizfzGqRyuv1sOfFsBLwKcLAivhHXNRbmYAFzQJ6bhXCQOEsPMIosgpTLnsPqUc+oJrW0H1Njcuvosz1vHoVVnwzdI2VQf2XF330ApR8s= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2618 Resent-From: Resent-To: br@brianrosen.net, hgs+ecrit@cs.columbia.edu, hannes.tschofenig@arm.com, rg+ietf@coretechnologyconsulting.com, allison.mankin@gmail.com, roger.marshall@comtechtel.com, barryleiba@computer.org, adam@nostrum.com, aamelnikov@fastmail.fm, Allison Mankin , draft-ietf-ecrit-data-only-ea@ietf.org, ecrit@ietf.org Resent-Message-Id: <20190828163355.8CA501200B2@ietfa.amsl.com> Resent-Date: Wed, 28 Aug 2019 09:33:55 -0700 (PDT) Archived-At: Subject: Re: [Ecrit] Genart last call review of draft-ietf-ecrit-data-only-ea-18 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 16:33:56 -0000 --_000_97271f7d5430957effb3cfa83cd3d915ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4sDQoNClRoYW5rIHlvdSBmb3IgdGhlIGxpZ2h0ZW5pbmcgZmFzdCByZXNwb25zZS4N Cg0KSSB1bmRlcnN0YW5kIHRoYXQgcGlja2luZyB0aGUgY29ycmVjdCB3b3JkaW5nIGhlcmUgaXMg aGFyZC4gVGhhbmsgeW91IGZvciB0YWtpbmcgdGhpcyBkaXNjdXNzaW9uIGJhY2sgdG8gdGhlIHdv cmtpbmcgZ3JvdXAuIFdoYXRldmVyIHRoZSB3b3JraW5nIGdyb3VwIGV2ZW50dWFsbHkgZGVjaWRl cyBpcyBva2F5IGZvciBtZS4gQWx0aG91Z2ggSSBzdGlsbCB3b25kZXIgaWYgbm90aWZpY2F0aW9u LW9ubHkgZW1lcmdlbmN5IGNhbGwgaXMgc3VpdGFibGU/DQoNCkkga25vdyB0aGF0IGVtZXJnZW5j eSBjYWxscyBhcmUgYWNjZXB0ZWQgZnJvbSBhbnlvbmUsIGV2ZW4gZnJvbSBkZXZpY2VzIHRoYXQg ZG9uJ3QgaGF2ZSBhIFNJTSBjYXJkIGZvciBleGFtcGxlLiBXaGljaCBpcyB3aHkgSSB0aGluayB0 aGUgd29yZGluZyBzaG91bGQgYmUgImlzIGxpa2VseSB0byByZWNlaXZlIGFuZA0KYWNjZXB0IGFs ZXJ0cyBmcm9tIGVudGl0aWVzIGl0IGNhbm5vdCBhdXRoZW50aWNhdGUuIiBUaGVyZSBpcyBhIHJl ZmVyZW5jZSB0byBSRkMgNjg4MSBpbiB0aGUgZm9sbG93aW5nIHNlbnRlbmNlLiBJIGxvb2tlZCBh dCBSRkMgNjg4MSBicmllZmx5IGFuZCBpdCBvbmx5IHRhbGtzIGFib3V0IHVuYXV0aGVudGljYXRl ZCBkZXZpY2VzIGJ1dCBub3RoaW5nIGFib3V0IHVuYXV0aG9yaXplZCBkZXZpY2VzLiBJIHRoaW5r IHRoYXQgcmVjZWl2aW5nIGFsZXJ0cyBmcm9tIGRldmljZXMgd2hpY2ggYXJlIG5vdCBhdXRoZW50 aWNhdGVkIGNvdmVycyBhIGJyb2FkZXIgY2FzZSB0aGFuIGRldmljZXMgd2hpY2ggYXJlIGF1dGhl bnRpY2F0ZWQgYnV0IG5vdCBhdXRob3JpemVkLiBIb3dldmVyLCBJIGRvbid0IGhhdmUgZW5vdWdo IGNvbnRleHQgdG8gYmUgc3VyZSBhbmQgSSB0cnVzdCB5b3VyIGp1ZGdtZW50IG9uIHRoaXMuDQoN Ci0tTW9oaXQNCg0KT24gOC8yOC8xOSA2OjUzIFBNLCBCcmlhbiBSb3NlbiB3cm90ZToNCg0KVGhh bmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciByZXZpZXcuDQoNClRoZSB0ZXJtIHdlIHVzZSBmb3Ig dGhlc2Uga2luZHMgb2Yg4oCcY2FsbHPigJ0gaGFzIGNoYW5nZWQgc2V2ZXJhbCB0aW1lcy4gIFRo ZXJlIHJlYWxseSBpc27igJl0IGEgZ3JlYXQgbmFtZS4NCkluIGFub3RoZXIgZm9ydW0sIHdl4oCZ cmUgY2FsbGluZyB0aGVtIOKAnG5vbi1odW1hbi1pbml0aWF0ZWTigJ0sIGJ1dCB0aGF0IHJlYWxs eSBpc27igJl0IHJpZ2h0IGVpdGhlci4gIElmIHlvdSBwcmVzcyBhIGJ1dHRvbiBhbmQgYSBkZXZp Y2Ugc2VuZHMgeW91ciBsb2NhdGlvbiBhbmQgc29tZSBtZWRpY2FsIGRhdGEsIHRoZW4gaXQgSVMg aHVtYW4gaW5pdGlhdGVkLg0KDQpUaGUgZGlmZmVyZW50aWF0aW9uIHRoYXQgbWF0dGVycyBpcyB3 aGV0aGVyIHRoZXJlIGlzIHR3byB3YXkgaW50ZXJhY3RpdmUgbWVkaWEgb3Igbm90LCB3aGljaCBh bHNvIG1lYW5zIHdoZXRoZXIgdGhlcmUgaXMgYSBzZXNzaW9uIG9yIG5vdC4NCk1vc3Qgb2YgdGhl c2Ug4oCcY2FsbHPigJ0gd2lsbCBiZSBmcm9tIHNlbnNvcnMsIGFuZCByZWFsbHkgYXJlIGRhdGEt b25seSwgYW5kIEkgdGhpbmsgdGhlIGRpZmZlcmVudGlhdGlvbiBiZXR3ZWVuIGRhdGEgYW5kIG1l ZGlhIGlzIGNsZWFyIGFuZCBub3QgY29uZnVzaW5nLiAgQnV0IHlvdSBjb3VsZCBoYXZlIG9uZSB3 YXksIG5vbiBpbnRlcmFjdGl2ZSBtZWRpYSBzaWduYWxlZCB3aXRoIHRoZXNlIGNhbGxzIChhIHN1 cnZlaWxsYW5jZSBjYW1lcmEgZm9yIGV4YW1wbGUpLiAgVGhlIGNhbGwgd291bGQgYmUgc2Vzc2lv bi1sZXNzLiAgVGhlIGNhbWVyYSBpbmZvcm1hdGlvbiB3b3VsZCBiZSBwYXNzZWQgYXMgYSBVUkkg dG8gYW4gUlRTUCBtZWRpYSBzdHJlYW0sIHNvIHdoYXQgaXMgcGFzc2VkIHJlYWxseSBpcyBkYXRh ICh0aGUgVVJMKSBhbmQgbm90IHRoZSBtZWRpYSwgYnV0IHRoZXJlIElTIG1lZGlhIGludm9sdmVk LCBzbyDigJxkYXRhLW9ubHnigJ0gaXNu4oCZdCBncmVhdC4NCg0K4oCcTm9uIEludGVyYWN0aXZl 4oCdIG1heSBhbHNvIG5vdCBiZSBxdWl0ZSByaWdodDogSWYgYW4gZWxldmF0b3Igc2VuZHMgeW91 IGFuIGFsZXJ0IGFuZCBhbHNvIGdpdmVzIHJlc3BvbmRlcnMgYWNjZXNzIHRvIGNvbnRyb2wgaXQs IGlzIHRoYXQgaW50ZXJhY3RpdmU/ICBUaGUg4oCcY2FsbOKAnSBpc27igJl0LCBidXQgdGhlIG5h bWUgY291bGQgYmUgbWlzbGVhZGluZy4NCg0KSW4gdGhlIGVuZCwgSSBkb27igJl0IHRoaW5rIGNo YW5naW5nIHRoZSBuYW1lIGlzIHdvcnRoIHdoaWxlLiAgSXTigJlzIGZhaXJseSBhY2N1cmF0ZSwg bm90IGNvbmZ1c2luZy4gIEnigJlkIGJlIG9rYXkgd2l0aCBjaGFuZ2luZyBpdCB0byDigJxOb24t SHVtYW4tSW5pdGlhdGVk4oCdLCBidXQgdGhhdCBoYXMgcHJvYmxlbXMgYWxzby4gIEkgd2lsbCB0 YWtlIHRoaXMgZGlzY3Vzc2lvbiBiYWNrIHRvIHRoZSB3b3JrIGdyb3VwIHRob3VnaCwNCg0K4oCc QXV0aG9yaXpl4oCdIHJlYWxseSBpcyB0aGUgcmlnaHQgd29yZC4gIFdlIG1heSBiZSBhYmxlIHRv IGF1dGhlbnRpY2F0ZSB5b3UgKHVzaW5nIHN0aXIgZm9yIGV4YW1wbGUpLCBidXQgd2UgdXN1YWxs eSBkb27igJl0IGhhdmUgYW55IGF1dGhvcml6YXRpb24gbWVjaGFuaXNtIC0gdW5sZXNzIHdl4oCZ cmUgdW5kZXIgYXR0YWNrLCB3ZSB0YWtlIGNhbGxzIGZyb20gYW55b25lLiAgVGhhdOKAmXMgdGhl IG5hdHVyZSBvZiBlbWVyZ2VuY3kgY2FsbHMuICBJbiB0aGUgVVMsIHlvdSBjYW4gZ2V0IGFuIGVt ZXJnZW5jeSBjYWxsIGZyb20gYSBtb2JpbGUgdGhhdCBoYXMgbm8gc2VydmljZS4NCg0KSeKAmWxs IGRvIHRoZSBlZGl0cyBmb3IgdGhlIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gaW4gdGhlIHBhcmFt ZXRlci4gIFBJREYtTE8gaXMgaG93IGVtZXJnZW5jeSBjYWxscyBzZW5kIGxvY2F0aW9uLiAgSeKA mWxsIGltcHJvdmUgdGhhdCB0ZXh0LiAgQWxzbyB3aWxsIHN1YnN0aXR1dGUg4oCcZGV0ZWN0c+KA nSBmb3Ig4oCcdW5kZXJzdGFuZHPigJ0gYW5kIGZpeCB0aGUgbml0cy4NCg0KDQpCcmlhbg0KDQoN Cg0KDQpPbiBBdWcgMjgsIDIwMTksIGF0IDk6MzggQU0sIE1vaGl0IFNldGhpIHZpYSBEYXRhdHJh Y2tlciA8bm9yZXBseUBpZXRmLm9yZz48bWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0K DQpSZXZpZXdlcjogTW9oaXQgU2V0aGkNClJldmlldyByZXN1bHQ6IFJlYWR5IHdpdGggSXNzdWVz DQoNCkkgYW0gdGhlIGFzc2lnbmVkIEdlbi1BUlQgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRo ZSBHZW5lcmFsIEFyZWENClJldmlldyBUZWFtIChHZW4tQVJUKSByZXZpZXdzIGFsbCBJRVRGIGRv Y3VtZW50cyBiZWluZyBwcm9jZXNzZWQNCmJ5IHRoZSBJRVNHIGZvciB0aGUgSUVURiBDaGFpci4g IFBsZWFzZSB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0DQpsaWtlIGFueSBvdGhlciBsYXN0IGNh bGwgY29tbWVudHMuDQoNCkZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBGQVEg YXQNCg0KPGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2dlbi93aWtpL0dlbkFydGZhcT48aHR0 cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvZ2VuL3dpa2kvR2VuQXJ0ZmFxPi4NCg0KRG9jdW1lbnQ6 IGRyYWZ0LWlldGYtZWNyaXQtZGF0YS1vbmx5LWVhLTE4DQpSZXZpZXdlcjogTW9oaXQgU2V0aGkN ClJldmlldyBEYXRlOiAyMDE5LTA4LTI4DQpJRVRGIExDIEVuZCBEYXRlOiAyMDE5LTA5LTAyDQpJ RVNHIFRlbGVjaGF0IGRhdGU6IE5vdCBzY2hlZHVsZWQgZm9yIGEgdGVsZWNoYXQNCg0KU3VtbWFy eTogVGhpcyBkcmFmdCBpcyBhbG1vc3QgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLCBidXQgaGFzIHNv bWUgaXNzdWVzIHRoYXQNCmNvbmNlcm4gbWUuIFRoZSBtb3N0IGltcG9ydGFudCBvbmUgaXMgdGhl IGNob2ljZSBvZiB0aGUgdGVybSAiZGF0YS1vbmx5Ii4NCg0KTWFqb3IgaXNzdWVzOiBJIGFtIHVu c3VyZSB3aHkgdGhlIGF1dGhvcnMgYW5kIHRoZSBXRyBjaG9zZSB0aGUgdGVybSBkYXRhLW9ubHkN CmVtZXJnZW5jeSBjYWxsPyBGaXJzdCwgSSB0aG91Z2h0IHRoYXQgaXQgaXMgcmVmZXJyaW5nIHRv IGEgdW5pZGlyZWN0aW9uYWwgY2FsbA0KYnV0IHRoYXQgaXNuJ3QgdGhlIGNhc2UgaGVyZS4gQWxz bywgYXJlbid0IGludGVyYWN0aXZlIFJUUCBzZXNzaW9ucyBhbHNvDQplc3NlbnRpYWxseSBjb21w b3NlZCBvZiBkYXRhIHBhY2tldHM/DQoNClBlcmhhcHMgbm90aWZpY2F0aW9uLW9ubHkgYW5kL29y IG5vbi1pbnRlcmF0aXZlIGVtZXJnZW5jeSBjYWxscyBjb3VsZCBiZQ0KY29uc2lkZXJlZCBhcyBh biBhbHRlcm5hdGl2ZS4NCg0KTWlub3IgaXNzdWVzOiBUaGUgdGV4dCBzYXlzICJBIFBTQVAsIGZv ciBleGFtcGxlLCBpcyBsaWtlbHkgdG8gcmVjZWl2ZSBhbmQNCmFjY2VwdCBhbGVydHMgZnJvbSBl bnRpdGllcyBpdCBjYW5ub3QgYXV0aG9yaXplLiIuIElzIGF1dGhvcml6ZSB0aGUgY29ycmVjdA0K d29yZD8gZGlkIHlvdSBtZWFuIGF1dGhlbnRpY2F0ZT8gWW91IG5lZWQgdG8gYXV0aGVudGljYXRl IGJlZm9yZSB5b3UgYXV0aG9yaXplLg0KDQpwYXJhbWV0ZXI6IE1BWSBjb250YWluIGFkZGl0aW9u YWwgaW5mb3JtYXRpb24uIElzIGl0IEFTQ0lJPyBIb3cgbG9uZyBjYW4gaXQgYmU/DQpJIHByZXN1 bWUgdGhhdCB0aGUgQ0FQIGhhcyBzb21lIGNsZWFybGVyIGd1aWRlbGluZS4gQXQgbGVhc3QgeW91 IGNvdWxkIHdyaXRlDQp0aGF0IHRoZSBDQVAgcmVzdHJpY3Rpb25zIGFwcGx5DQoNClRoZSB0ZXh0 IHNheXMgc29tZXRoaW5nIGFib3V0IFBJREYtTE8gc3RydWN0dXJlIHJlZmVyZW5jZWQgYnk/IEkg YW0gbm90IHN1cmUNCndoYXQgaXMgbWVhbnQgaGVyZT8gUGVyaGFwcyBzb21lIG1vcmUgdGV4dCBo ZXJlIHdvdWxkIGhlbHAgdGhlIHJlYWRlcg0KdW5kZXJzdGFuZCBiZXR0ZXIuDQoNClRoZSB0ZXh0 IHNheXMgIkEgU0lQIGludGVybWVkaWFyeSBjYW4gYWxzbyByZWplY3QgYW4gYWxlcnQgaXQgcmVj ZWl2ZXMgZnJvbSBhDQpVc2VyIEFnZW50IChVQSkgd2hlbiBpdCB1bmRlcnN0YW5kcyB0aGF0IHRo ZSBwcm92aWRlZCBhbGVydCBpcyBtYWxmb3JtZWQuIi4NClBlcmhhcHMgZGV0ZWN0cyBpcyBiZXR0 ZXIgY2hvaWNlIHRoYW4gdW5kZXJzdGFuZC4gSXQgY2Fubm90IHVuZGVyc3RhbmQNCnNvbWV0aGlu ZyB0aGF0IGlzIG1hbGZvcm1lZC4NCg0KTml0cy9lZGl0b3JpYWwgY29tbWVudHM6DQoNCmNpdGl6 ZW4vaW5kaXZpZHVhbCAtPiBjaXRpemVucy9pbmRpdmlkdWFscw0KU2VuZGluZyBhIG5vbi1pbnRl cmFjdGl2ZSBjYWxsIGNvbnRhaW5pbmcgb25seSBkYXRhIHRvd2FyZCBhIC0+IG9ubHkgZGF0YQ0K dG93YXJkcyBhIEZpZ3VyZXMgMSBhbmQgMiBjb3VsZCBoYXZlIG1vcmUgaW5mby4gSXMgaXQgYSBI VFRQIG9yIFNJUCAyMDAgKE9LKT8NCmFuZCB0aGUgcmVjaXBpZW50IHVzaW5nIEhUVFBTIHRvIHJl dHJpZXZlIHRoZSBkYXRhLiAgLT4gYW5kIHRoZSByZWNpcGllbnQgdXNlcw0KSFRUUFMgdG8gcmV0 cmlldmUgdGhlIGRhdGEuDQoNCg0KDQoNCg0K --_000_97271f7d5430957effb3cfa83cd3d915ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <1D29C38EFEBA644684A0C2D45D59C996@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IiNGRkZG RkYiIHRleHQ9IiMwMDAwMDAiPg0KPHA+SGkgQnJpYW4sPC9wPg0KPHA+VGhhbmsgeW91IGZvciB0 aGUgbGlnaHRlbmluZyBmYXN0IHJlc3BvbnNlLiA8YnI+DQo8L3A+DQo8cD5JIHVuZGVyc3RhbmQg dGhhdCBwaWNraW5nIHRoZSBjb3JyZWN0IHdvcmRpbmcgaGVyZSBpcyBoYXJkLiBUaGFuayB5b3Ug Zm9yIHRha2luZyB0aGlzIGRpc2N1c3Npb24gYmFjayB0byB0aGUgd29ya2luZyBncm91cC4gV2hh dGV2ZXIgdGhlIHdvcmtpbmcgZ3JvdXAgZXZlbnR1YWxseSBkZWNpZGVzIGlzIG9rYXkgZm9yIG1l LiBBbHRob3VnaCBJIHN0aWxsIHdvbmRlciBpZg0KPGI+bm90aWZpY2F0aW9uLW9ubHkgZW1lcmdl bmN5IGNhbGw8L2I+IGlzIHN1aXRhYmxlPyA8YnI+DQo8L3A+DQo8cD5JIGtub3cgdGhhdCBlbWVy Z2VuY3kgY2FsbHMgYXJlIGFjY2VwdGVkIGZyb20gYW55b25lLCBldmVuIGZyb20gZGV2aWNlcyB0 aGF0IGRvbid0IGhhdmUgYSBTSU0gY2FyZCBmb3IgZXhhbXBsZS4gV2hpY2ggaXMgd2h5IEkgdGhp bmsgdGhlIHdvcmRpbmcgc2hvdWxkIGJlICZxdW90O2lzIGxpa2VseSB0byByZWNlaXZlIGFuZDxi cj4NCmFjY2VwdCBhbGVydHMgZnJvbSBlbnRpdGllcyBpdCBjYW5ub3QgYXV0aGVudGljYXRlLiZx dW90OyBUaGVyZSBpcyBhIHJlZmVyZW5jZSB0byBSRkMgNjg4MSBpbiB0aGUgZm9sbG93aW5nIHNl bnRlbmNlLiBJIGxvb2tlZCBhdCBSRkMgNjg4MSBicmllZmx5IGFuZCBpdCBvbmx5IHRhbGtzIGFi b3V0IHVuYXV0aGVudGljYXRlZCBkZXZpY2VzIGJ1dCBub3RoaW5nIGFib3V0IHVuYXV0aG9yaXpl ZCBkZXZpY2VzLiBJIHRoaW5rIHRoYXQgcmVjZWl2aW5nIGFsZXJ0cw0KIGZyb20gZGV2aWNlcyB3 aGljaCBhcmUgbm90IGF1dGhlbnRpY2F0ZWQgY292ZXJzIGEgYnJvYWRlciBjYXNlIHRoYW4gZGV2 aWNlcyB3aGljaCBhcmUgYXV0aGVudGljYXRlZCBidXQgbm90IGF1dGhvcml6ZWQuIEhvd2V2ZXIs IEkgZG9uJ3QgaGF2ZSBlbm91Z2ggY29udGV4dCB0byBiZSBzdXJlIGFuZCBJIHRydXN0IHlvdXIg anVkZ21lbnQgb24gdGhpcy4NCjwvcD4NCjxwPi0tTW9oaXQ8YnI+DQo8L3A+DQo8ZGl2IGNsYXNz PSJtb3otY2l0ZS1wcmVmaXgiPk9uIDgvMjgvMTkgNjo1MyBQTSwgQnJpYW4gUm9zZW4gd3JvdGU6 PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJtaWQ6QjAyREIzNjYt QjVGQy00ODE2LThBOEQtMzg2MjA2ODg4NUU4QGJyaWFucm9zZW4ubmV0Ij4NCjxwcmUgY2xhc3M9 Im1vei1xdW90ZS1wcmUiIHdyYXA9IiI+VGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciByZXZp ZXcuDQoNClRoZSB0ZXJtIHdlIHVzZSBmb3IgdGhlc2Uga2luZHMgb2Yg4oCcY2FsbHPigJ0gaGFz IGNoYW5nZWQgc2V2ZXJhbCB0aW1lcy4gIFRoZXJlIHJlYWxseSBpc27igJl0IGEgZ3JlYXQgbmFt ZS4NCkluIGFub3RoZXIgZm9ydW0sIHdl4oCZcmUgY2FsbGluZyB0aGVtIOKAnG5vbi1odW1hbi1p bml0aWF0ZWTigJ0sIGJ1dCB0aGF0IHJlYWxseSBpc27igJl0IHJpZ2h0IGVpdGhlci4gIElmIHlv dSBwcmVzcyBhIGJ1dHRvbiBhbmQgYSBkZXZpY2Ugc2VuZHMgeW91ciBsb2NhdGlvbiBhbmQgc29t ZSBtZWRpY2FsIGRhdGEsIHRoZW4gaXQgSVMgaHVtYW4gaW5pdGlhdGVkLg0KDQpUaGUgZGlmZmVy ZW50aWF0aW9uIHRoYXQgbWF0dGVycyBpcyB3aGV0aGVyIHRoZXJlIGlzIHR3byB3YXkgaW50ZXJh Y3RpdmUgbWVkaWEgb3Igbm90LCB3aGljaCBhbHNvIG1lYW5zIHdoZXRoZXIgdGhlcmUgaXMgYSBz ZXNzaW9uIG9yIG5vdC4gDQpNb3N0IG9mIHRoZXNlIOKAnGNhbGxz4oCdIHdpbGwgYmUgZnJvbSBz ZW5zb3JzLCBhbmQgcmVhbGx5IGFyZSBkYXRhLW9ubHksIGFuZCBJIHRoaW5rIHRoZSBkaWZmZXJl bnRpYXRpb24gYmV0d2VlbiBkYXRhIGFuZCBtZWRpYSBpcyBjbGVhciBhbmQgbm90IGNvbmZ1c2lu Zy4gIEJ1dCB5b3UgY291bGQgaGF2ZSBvbmUgd2F5LCBub24gaW50ZXJhY3RpdmUgbWVkaWEgc2ln bmFsZWQgd2l0aCB0aGVzZSBjYWxscyAoYSBzdXJ2ZWlsbGFuY2UgY2FtZXJhIGZvciBleGFtcGxl KS4gIFRoZSBjYWxsIHdvdWxkIGJlIHNlc3Npb24tbGVzcy4gIFRoZSBjYW1lcmEgaW5mb3JtYXRp b24gd291bGQgYmUgcGFzc2VkIGFzIGEgVVJJIHRvIGFuIFJUU1AgbWVkaWEgc3RyZWFtLCBzbyB3 aGF0IGlzIHBhc3NlZCByZWFsbHkgaXMgZGF0YSAodGhlIFVSTCkgYW5kIG5vdCB0aGUgbWVkaWEs IGJ1dCB0aGVyZSBJUyBtZWRpYSBpbnZvbHZlZCwgc28g4oCcZGF0YS1vbmx54oCdIGlzbuKAmXQg Z3JlYXQuDQoNCuKAnE5vbiBJbnRlcmFjdGl2ZeKAnSBtYXkgYWxzbyBub3QgYmUgcXVpdGUgcmln aHQ6IElmIGFuIGVsZXZhdG9yIHNlbmRzIHlvdSBhbiBhbGVydCBhbmQgYWxzbyBnaXZlcyByZXNw b25kZXJzIGFjY2VzcyB0byBjb250cm9sIGl0LCBpcyB0aGF0IGludGVyYWN0aXZlPyAgVGhlIOKA nGNhbGzigJ0gaXNu4oCZdCwgYnV0IHRoZSBuYW1lIGNvdWxkIGJlIG1pc2xlYWRpbmcuDQoNCklu IHRoZSBlbmQsIEkgZG9u4oCZdCB0aGluayBjaGFuZ2luZyB0aGUgbmFtZSBpcyB3b3J0aCB3aGls ZS4gIEl04oCZcyBmYWlybHkgYWNjdXJhdGUsIG5vdCBjb25mdXNpbmcuICBJ4oCZZCBiZSBva2F5 IHdpdGggY2hhbmdpbmcgaXQgdG8g4oCcTm9uLUh1bWFuLUluaXRpYXRlZOKAnSwgYnV0IHRoYXQg aGFzIHByb2JsZW1zIGFsc28uICBJIHdpbGwgdGFrZSB0aGlzIGRpc2N1c3Npb24gYmFjayB0byB0 aGUgd29yayBncm91cCB0aG91Z2gsDQoNCuKAnEF1dGhvcml6ZeKAnSByZWFsbHkgaXMgdGhlIHJp Z2h0IHdvcmQuICBXZSBtYXkgYmUgYWJsZSB0byBhdXRoZW50aWNhdGUgeW91ICh1c2luZyBzdGly IGZvciBleGFtcGxlKSwgYnV0IHdlIHVzdWFsbHkgZG9u4oCZdCBoYXZlIGFueSBhdXRob3JpemF0 aW9uIG1lY2hhbmlzbSAtIHVubGVzcyB3ZeKAmXJlIHVuZGVyIGF0dGFjaywgd2UgdGFrZSBjYWxs cyBmcm9tIGFueW9uZS4gIFRoYXTigJlzIHRoZSBuYXR1cmUgb2YgZW1lcmdlbmN5IGNhbGxzLiAg SW4gdGhlIFVTLCB5b3UgY2FuIGdldCBhbiBlbWVyZ2VuY3kgY2FsbCBmcm9tIGEgbW9iaWxlIHRo YXQgaGFzIG5vIHNlcnZpY2UuDQoNCknigJlsbCBkbyB0aGUgZWRpdHMgZm9yIHRoZSBhZGRpdGlv bmFsIGluZm9ybWF0aW9uIGluIHRoZSBwYXJhbWV0ZXIuICBQSURGLUxPIGlzIGhvdyBlbWVyZ2Vu Y3kgY2FsbHMgc2VuZCBsb2NhdGlvbi4gIEnigJlsbCBpbXByb3ZlIHRoYXQgdGV4dC4gIEFsc28g d2lsbCBzdWJzdGl0dXRlIOKAnGRldGVjdHPigJ0gZm9yIOKAnHVuZGVyc3RhbmRz4oCdIGFuZCBm aXggdGhlIG5pdHMuDQoNCg0KQnJpYW4NCg0KDQo8L3ByZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPg0KPHByZSBjbGFzcz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj5PbiBBdWcgMjgsIDIwMTks IGF0IDk6MzggQU0sIE1vaGl0IFNldGhpIHZpYSBEYXRhdHJhY2tlciA8YSBjbGFzcz0ibW96LXR4 dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86bm9yZXBseUBpZXRmLm9yZyI+Jmx0O25vcmVw bHlAaWV0Zi5vcmcmZ3Q7PC9hPiB3cm90ZToNCg0KUmV2aWV3ZXI6IE1vaGl0IFNldGhpDQpSZXZp ZXcgcmVzdWx0OiBSZWFkeSB3aXRoIElzc3Vlcw0KDQpJIGFtIHRoZSBhc3NpZ25lZCBHZW4tQVJU IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgR2VuZXJhbCBBcmVhDQpSZXZpZXcgVGVhbSAo R2VuLUFSVCkgcmV2aWV3cyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkDQpieSB0 aGUgSUVTRyBmb3IgdGhlIElFVEYgQ2hhaXIuICBQbGVhc2UgdHJlYXQgdGhlc2UgY29tbWVudHMg anVzdA0KbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpGb3IgbW9yZSBpbmZv cm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgRkFRIGF0DQoNCjxhIGNsYXNzPSJtb3otdHh0LWxpbmst cmZjMjM5NkUiIGhyZWY9Imh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2dlbi93aWtpL0dlbkFy dGZhcSI+Jmx0O2h0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2dlbi93aWtpL0dlbkFydGZhcSZn dDs8L2E+Lg0KDQpEb2N1bWVudDogZHJhZnQtaWV0Zi1lY3JpdC1kYXRhLW9ubHktZWEtMTgNClJl dmlld2VyOiBNb2hpdCBTZXRoaQ0KUmV2aWV3IERhdGU6IDIwMTktMDgtMjgNCklFVEYgTEMgRW5k IERhdGU6IDIwMTktMDktMDINCklFU0cgVGVsZWNoYXQgZGF0ZTogTm90IHNjaGVkdWxlZCBmb3Ig YSB0ZWxlY2hhdA0KDQpTdW1tYXJ5OiBUaGlzIGRyYWZ0IGlzIGFsbW9zdCByZWFkeSBmb3IgcHVi bGljYXRpb24sIGJ1dCBoYXMgc29tZSBpc3N1ZXMgdGhhdA0KY29uY2VybiBtZS4gVGhlIG1vc3Qg aW1wb3J0YW50IG9uZSBpcyB0aGUgY2hvaWNlIG9mIHRoZSB0ZXJtICZxdW90O2RhdGEtb25seSZx dW90Oy4NCg0KTWFqb3IgaXNzdWVzOiBJIGFtIHVuc3VyZSB3aHkgdGhlIGF1dGhvcnMgYW5kIHRo ZSBXRyBjaG9zZSB0aGUgdGVybSBkYXRhLW9ubHkNCmVtZXJnZW5jeSBjYWxsPyBGaXJzdCwgSSB0 aG91Z2h0IHRoYXQgaXQgaXMgcmVmZXJyaW5nIHRvIGEgdW5pZGlyZWN0aW9uYWwgY2FsbA0KYnV0 IHRoYXQgaXNuJ3QgdGhlIGNhc2UgaGVyZS4gQWxzbywgYXJlbid0IGludGVyYWN0aXZlIFJUUCBz ZXNzaW9ucyBhbHNvDQplc3NlbnRpYWxseSBjb21wb3NlZCBvZiBkYXRhIHBhY2tldHM/DQoNClBl cmhhcHMgbm90aWZpY2F0aW9uLW9ubHkgYW5kL29yIG5vbi1pbnRlcmF0aXZlIGVtZXJnZW5jeSBj YWxscyBjb3VsZCBiZQ0KY29uc2lkZXJlZCBhcyBhbiBhbHRlcm5hdGl2ZS4NCg0KTWlub3IgaXNz dWVzOiBUaGUgdGV4dCBzYXlzICZxdW90O0EgUFNBUCwgZm9yIGV4YW1wbGUsIGlzIGxpa2VseSB0 byByZWNlaXZlIGFuZA0KYWNjZXB0IGFsZXJ0cyBmcm9tIGVudGl0aWVzIGl0IGNhbm5vdCBhdXRo b3JpemUuJnF1b3Q7LiBJcyBhdXRob3JpemUgdGhlIGNvcnJlY3QNCndvcmQ/IGRpZCB5b3UgbWVh biBhdXRoZW50aWNhdGU/IFlvdSBuZWVkIHRvIGF1dGhlbnRpY2F0ZSBiZWZvcmUgeW91IGF1dGhv cml6ZS4NCg0KcGFyYW1ldGVyOiBNQVkgY29udGFpbiBhZGRpdGlvbmFsIGluZm9ybWF0aW9uLiBJ cyBpdCBBU0NJST8gSG93IGxvbmcgY2FuIGl0IGJlPw0KSSBwcmVzdW1lIHRoYXQgdGhlIENBUCBo YXMgc29tZSBjbGVhcmxlciBndWlkZWxpbmUuIEF0IGxlYXN0IHlvdSBjb3VsZCB3cml0ZQ0KdGhh dCB0aGUgQ0FQIHJlc3RyaWN0aW9ucyBhcHBseQ0KDQpUaGUgdGV4dCBzYXlzIHNvbWV0aGluZyBh Ym91dCBQSURGLUxPIHN0cnVjdHVyZSByZWZlcmVuY2VkIGJ5PyBJIGFtIG5vdCBzdXJlDQp3aGF0 IGlzIG1lYW50IGhlcmU/IFBlcmhhcHMgc29tZSBtb3JlIHRleHQgaGVyZSB3b3VsZCBoZWxwIHRo ZSByZWFkZXINCnVuZGVyc3RhbmQgYmV0dGVyLg0KDQpUaGUgdGV4dCBzYXlzICZxdW90O0EgU0lQ IGludGVybWVkaWFyeSBjYW4gYWxzbyByZWplY3QgYW4gYWxlcnQgaXQgcmVjZWl2ZXMgZnJvbSBh DQpVc2VyIEFnZW50IChVQSkgd2hlbiBpdCB1bmRlcnN0YW5kcyB0aGF0IHRoZSBwcm92aWRlZCBh bGVydCBpcyBtYWxmb3JtZWQuJnF1b3Q7Lg0KUGVyaGFwcyBkZXRlY3RzIGlzIGJldHRlciBjaG9p Y2UgdGhhbiB1bmRlcnN0YW5kLiBJdCBjYW5ub3QgdW5kZXJzdGFuZA0Kc29tZXRoaW5nIHRoYXQg aXMgbWFsZm9ybWVkLg0KDQpOaXRzL2VkaXRvcmlhbCBjb21tZW50czoNCg0KY2l0aXplbi9pbmRp dmlkdWFsIC0mZ3Q7IGNpdGl6ZW5zL2luZGl2aWR1YWxzDQpTZW5kaW5nIGEgbm9uLWludGVyYWN0 aXZlIGNhbGwgY29udGFpbmluZyBvbmx5IGRhdGEgdG93YXJkIGEgLSZndDsgb25seSBkYXRhDQp0 b3dhcmRzIGEgRmlndXJlcyAxIGFuZCAyIGNvdWxkIGhhdmUgbW9yZSBpbmZvLiBJcyBpdCBhIEhU VFAgb3IgU0lQIDIwMCAoT0spPw0KYW5kIHRoZSByZWNpcGllbnQgdXNpbmcgSFRUUFMgdG8gcmV0 cmlldmUgdGhlIGRhdGEuICAtJmd0OyBhbmQgdGhlIHJlY2lwaWVudCB1c2VzDQpIVFRQUyB0byBy ZXRyaWV2ZSB0aGUgZGF0YS4NCg0KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlIGNsYXNzPSJt b3otcXVvdGUtcHJlIiB3cmFwPSIiPg0KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_97271f7d5430957effb3cfa83cd3d915ericssoncom_-- From nobody Wed Aug 28 11:25:25 2019 Return-Path: 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 8498E120059 for ; Wed, 28 Aug 2019 11:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=moducom-com.20150623.gappssmtp.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 si1WsyghCMIj for ; Wed, 28 Aug 2019 11:25:23 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 4C0CF12001B for ; Wed, 28 Aug 2019 11:25:23 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id l7so1494461ioj.6 for ; Wed, 28 Aug 2019 11:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=moducom-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=xzIJ2DoIfnXsBfZ81vzIOd8Airfesd0ShbeHL4HQDOE=; b=BgcwEl8h06zOGaAQR7p3ZwZ6k9H44gNLVKO1mj48Y4S543SDLW441yWFZoRGKjN6WB V9dCDcMaeuLJNmEeYyZo6Si5wLzkMa2XW6yTEXC5SV+dK9bbP2kYAlYXJJLwirIxOAIt Wny+8ySN8bozd5pT3YJ59oCKnY+fDxR+azuosrSSszE2Wkqrsbq71O/cF3Nf1EFR/uty k4CUuz/K0keLTbeL8PYHHGpw+wMNDCdc4HntVfEVagA+Ohj5u2YZSLo++3L8fGHoe/xj 0w9fR+95aVPxqjlvR6p4tvREiGTHeYUhJ5oKiGG5aqspB/MfPyVT+m6mDrsRc/VTvRCS qzHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=xzIJ2DoIfnXsBfZ81vzIOd8Airfesd0ShbeHL4HQDOE=; b=jlSOchEPJ84IBDvenbnUamRpiGBu4WcdMV6KyikXRLxRLCM/ZjoOKoQWj0jwL6zyYr oUSzMdcqWwTX4KlgtQPcVeK/WLPLk5apDwGBZL0g8J51hjysKVq4nr9ZYuLCLStNpYmA yA5H5TGwY0DB9arLmnk9Ev/kXCLbnMG3halxqDioW4qabTS8QfzoyOHGfBo6q2tv6LU6 q01mf86rlj5AOz0jxNNcvKUEKDSAOo+VqwD7OGdKwhK5/jlG2DBbRs1QleAcqPchT10Y sUbXrrNb4N9gr2y8vfWMnTygs9HhlRWvgbYXAo54RtkBCQv5u+miP5QpX3WNK8/O1lXW IuOA== X-Gm-Message-State: APjAAAVh9JK7df7BNLCM1I7koYgS78APGu+hnBB7rhomCpuHyYyiT8va HiBraUomzuD2sYn89eZIMbgpQVNvYsMzWJ+9YOEgOV/8sfQ= X-Google-Smtp-Source: APXvYqxadTbIzri+WoRovLdzB7WRy4EB2WdI2Jm3tqkNtm+TlhhSOg51psXNkJ5iUQg1z1NVRYBTnT/HyVmP4uHhg3o= X-Received: by 2002:a02:8814:: with SMTP id r20mr5958595jai.126.1567016722445; Wed, 28 Aug 2019 11:25:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Malachi Burke Date: Wed, 28 Aug 2019 11:25:09 -0700 Message-ID: To: ecrit@ietf.org Content-Type: multipart/alternative; boundary="00000000000019531d059131839c" Archived-At: Subject: [Ecrit] Genart last call review of draft-ietf-ecrit-data-only-ea-18 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 18:25:25 -0000 --00000000000019531d059131839c Content-Type: text/plain; charset="UTF-8" In response to Mohit Sethi's comments: As a newcomer, I find your suggestion of "notification-only and/or non-intera[c]tive emergency calls" over "data-only" to be quite helpful. -- --- Malachi Burke ModUCom --00000000000019531d059131839c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In response to Mohit Sethi's comments:
=
As a newcomer, I find your suggestion of "notification-= only and/or non-intera[c]tive emergency calls" over "data-only&qu= ot; to be quite helpful.



--
---
Malachi Burke
ModUCom
=
--00000000000019531d059131839c-- From nobody Thu Aug 29 14:17:33 2019 Return-Path: X-Original-To: expand-draft-ietf-ecrit-data-only-ea.all@virtual.ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 1FDE3120073; Thu, 29 Aug 2019 14:17:16 -0700 (PDT) X-Original-To: xfilter-draft-ietf-ecrit-data-only-ea.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-ecrit-data-only-ea.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80804120803; Thu, 29 Aug 2019 14:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 58fyMN-Z77dV; Thu, 29 Aug 2019 14:17:11 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-oln040092004094.outbound.protection.outlook.com [40.92.4.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93DC2120073; Thu, 29 Aug 2019 14:17:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZTVKlgfLLMd1pju6PE1zK/o2V3N2DuWpJOKzkCIbWtl+9rXJ0ft/hAHo2Xvg02gWH6zP15p7Ngje8xAaIV+N9c4Wh5ci8Wm/cbV/LaLxTKadP+3nAMdQ26TxTRIsPcy6xLgUWqxNe9AYkKtbzuwT5PQA4Ta7cA/dFm1z+1Wb4I2n7zte0iFtuUC+Zy2UsxwCeLO/WAuBwClM9kgo83Pkhcro3hu1pzDyKUxCH+F7X3BavpZCOKD4kwfVlG+JKaBVI5JBZ24o3RgccrIgod+9UM0hCVzDRdrv0FF78YKHWBN4WtgRl6ziFFrGGZQCOgCdbGWWS5mOO4FpWiOYbSfMpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lqfDJjp/vIqiqtyt0HNB2QzCQufw2GtJMEgA2UZU3x0=; b=oVTDz+qwOrFfE/GhY+JKOh4kOHq3jUhy9uxlBuF7YwtZPuJHEovIkcJQ1DtDhy+0VC623Uny7O0OZbE0ufwaTU0r1gBhq293kJNqzy1U3iC1ZqtUQ+K5nWxlacdz6SQJReE5mQh0s+Zt5bWFP5rl0LQq+czBnfwTluTwV/kGa3SFFxafwAEbSoHLhcp7b8zjC8Uz4kZkJLy+RbNBlELsjVREocQ/V9UYE69zxHy53PosAX7tqqlzaD9k9pz2WTebuof1WPYvvsG+Ya6KohBMg4ZDOYtiZEkrDFiOupQE24/EYKM4L/Hqr+MQ53XLHiaMr+pib4h1GJCCCza7D/AL2A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lqfDJjp/vIqiqtyt0HNB2QzCQufw2GtJMEgA2UZU3x0=; b=B1O4YrvbfZnGPCaeIwo+xIxpQnSKQ3GmFu2eyIOSGecaJuqV12+wteVZb221nrY45gKNxgb/YAAlx+K1EPNQ2LiAx2IteSuJGpLTiZNJnMUTvke05tYCeURnZrE1dlKLEkaqT3qeNb386v5As0ZpaGbyPHwkwEP/mUBNF+m/evG1PArS2kzGsMxlGVF/eG7gHfBJDEpgMloh5LBDFCNC/KL9zmjQYQXX3pMg0BqNvd5gqrbBVrElAZGqgHL+Y+CMCY5D2qbphDue16eZu97ErKHHmyw2WinMfM1rSys23wSKx2HsGYQuJye7xgTyqCFOR+9payYQSwyhlkAYkkFmJw== Received: from SN1NAM02FT051.eop-nam02.prod.protection.outlook.com (10.152.72.59) by SN1NAM02HT189.eop-nam02.prod.protection.outlook.com (10.152.72.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2220.16; Thu, 29 Aug 2019 21:17:10 +0000 Received: from MWHPR04MB0367.namprd04.prod.outlook.com (10.152.72.60) by SN1NAM02FT051.mail.protection.outlook.com (10.152.73.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.16 via Frontend Transport; Thu, 29 Aug 2019 21:17:10 +0000 Received: from MWHPR04MB0367.namprd04.prod.outlook.com ([fe80::f019:9a3e:4580:6163]) by MWHPR04MB0367.namprd04.prod.outlook.com ([fe80::f019:9a3e:4580:6163%10]) with mapi id 15.20.2220.013; Thu, 29 Aug 2019 21:17:10 +0000 From: Charlie Kaufman To: Brian Rosen CC: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-ecrit-data-only-ea.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-ecrit-data-only-ea-18 Thread-Index: AQHVWrVSYrXYcnS0SkGl7pu26H6ueacN5f6AgAS+JZ0= Date: Thu, 29 Aug 2019 21:17:10 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:F2FA7D359EE27EFE341DD520161893FE06996FCEE4A317B3F061863488171CCE; UpperCasedChecksum:0202776B1821EAB52B0D2199FCC5B7E0FC945C68FC68949B1C2294346C3388E4; SizeAsReceived:7115; Count:44 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [ttr/i2OKYgvpzRkgCuIhjDqiaobV+vhzD8DHqdrDpT/RC3XSq23f0CmFmuOHljIL] x-ms-publictraffictype: Email x-incomingheadercount: 44 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(5050001)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322404)(2017031323274)(2017031324274)(1601125500)(1603101475)(1701031045); SRVR:SN1NAM02HT189; x-ms-traffictypediagnostic: SN1NAM02HT189: x-ms-exchange-purlcount: 3 x-microsoft-antispam-message-info: tHIdR4VdajhiPffjA5y8Tb+yiKdzqJ2mhe9J6vFrETqY6wWk+EAUkANTDkhZLxcsBNfydGUl2vBlUDGeMHN+UT93d9m6Ok+RZnWwgJma8Nyg1u5t89eIciEkXLac85ULuX0eSNIp8kbJL3/pq+AqNcmrUy+Lgwtxg+SvfM3TgxpuZ+Gjkxri6jdqR/85DNZ3 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MWHPR04MB036724650A0D208BE4D22D58DFA20MWHPR04MB0367namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 39064291-ff9a-447d-ed82-08d72cc640fd X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2019 21:17:10.0984 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT189 Resent-From: Resent-To: br@brianrosen.net, hgs+ecrit@cs.columbia.edu, hannes.tschofenig@arm.com, rg+ietf@coretechnologyconsulting.com, allison.mankin@gmail.com, roger.marshall@comtechtel.com, barryleiba@computer.org, adam@nostrum.com, aamelnikov@fastmail.fm, Allison Mankin , draft-ietf-ecrit-data-only-ea@ietf.org, ecrit@ietf.org Resent-Message-Id: <20190829211716.1FDE3120073@ietfa.amsl.com> Resent-Date: Thu, 29 Aug 2019 14:17:16 -0700 (PDT) Archived-At: Subject: Re: [Ecrit] Secdir review of draft-ietf-ecrit-data-only-ea-18 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 21:17:16 -0000 --_000_MWHPR04MB036724650A0D208BE4D22D58DFA20MWHPR04MB0367namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable My confusion had to do with whether this is adding new functionality or whe= ther this is a profiling of existing functionality to enable a lightweight = interaction. For example, is it possible to send a CAP message within a SIP= transaction when there is going to follow interactive two way media in the= existing protocol? If so, this could have been done with the previous prot= ocol just by ending after the first exchange. If not, this is something tha= t couldn't have been done before and this is new functionality (and I would= wonder why the old protocol did not allow this). My confusion might be based on my lack of understanding of the layering of = CAP, SIP, and MIME, and it could be that anyone with a legitimate reason to= read this document would not be confused. --Charlie p.s. Apologies for the formatting. I'm using Outlook's web interface, which= tends to be overly clever and mess things up. Sent from Outlook ________________________________ From: Brian Rosen Sent: Monday, August 26, 2019 1:34 PM To: Charlie Kaufman Cc: secdir@ietf.org ; iesg@ietf.org ; draft= -ietf-ecrit-data-only-ea.all@ietf.org Subject: Re: Secdir review of draft-ietf-ecrit-data-only-ea-18 Hi Charlie Thanks for the review, I appreciate it. The introduction section has this text Data-only emergency calls are similar to regular emergency calls in the sense that they require the emergency indications, emergency call routing functionality and may even have the same location requirements. However, the communication interaction will not lead to the exchange of interactive media, that is, Real-Time Protocol packets, such as voice, video data or real-time text. ... This document describes a method of including a CAP message in a SIP transaction by defining it as a block of "additional data" as defined in [RFC7852]. The CAP message is i= ncluded either by value (the CAP message is in the body of the message, using a CID) or by reference (a URI is included in the message, which when dereferenced returns the CAP message). The additional data mechanism is also used to send alert specific data beyond that available in the CAP message. This document also describes how a SIP MESSAGE [RFC3428] transaction can be used to send a data-only call. This says that this document describes how to send an emergency call when t= here is not two way interactive media (voice, video and/or text), and it sa= ys that the way you do that is to send a SIP MESSAGE, with a CAP message po= inted to by a Call-Info header. That text seems very clear to me, and yet you didn=92t read what we hoped i= nto what we wrote. I would really like to fix this, but I=92m at a loss to= understand what I need to do. I=92ll improve the acronym stuff. On Aug 24, 2019, at 3:53 PM, Charlie Kaufman > wrote: I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document defines a new MIME type: 'application/EmergencyCallData.cap+x= ml' for use primarily by sensors to send alert messages to emergency servic= es providers. It also defines a new Emergency Call Data Type: 'cap' in orde= r to embed this data efficiently in a SIP transaction. I saw no new securit= y issues beyond those already noted for the protocols carrying these messag= es. I do have some editorial suggestions: There is a lot of context that the authors assumed any reader would have th= at could have been stated in the introduction. I believe from context that = the purpose of this new MIME type is to support simple (IoT) sensors that d= on't want to implement a more heavyweight protocol, but I don't believe tha= t was stated anywhere. I got the impression that the functionality provided could have been done w= ith existing protocols by sending the CAP message over a SIP session, but t= hat doing so would place an unnecessary burden on simple (IoT) sensors, and= that this protocol would be easier for such sensors to implement for the l= imited cases such sensors need to deal with. If that's true, it should be s= tated. If not, the purpose of this protocol should be more clearly stated. These acronyms were used but never defined: SIP CID LoST These acronyms were expanded, but not in an easy to find place: Common Alerting Protocol (CAP) Public Safety Answering Points (PSAPs) Emergency Services Routing Proxy (ESRP) It would be nice to include them in the terminology section, ideally with a= reference to the RFC where more information is available. Typo: p17 "security mechanism" -> "security mechanisms" --Charlie --_000_MWHPR04MB036724650A0D208BE4D22D58DFA20MWHPR04MB0367namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
My confusion had to do with whether this is adding new functionality or whe= ther this is a profiling of existing functionality to enable a lightweight = interaction. For example, is it possible to send a CAP message within a SIP= transaction when there is going to follow interactive two way media in the existing protocol? If so, this = could have been done with the previous protocol just by ending after the fi= rst exchange. If not, this is something that couldn't have been done before= and this is new functionality (and I would wonder why the old protocol did not allow this).

My confusion might be based on my lack of understanding of the layering of = CAP, SIP, and MIME, and it could be that anyone with a legitimate reason to= read this document would not be confused.

--Charlie

p.s. Apologies for the formatting. I'm using Outlook's web interface, which= tends to be overly clever and mess things up.

Sent from Outlook


From: Brian Rosen <br@= brianrosen.net>
Sent: Monday, August 26, 2019 1:34 PM
To: Charlie Kaufman <charliekaufman@outlook.com>
Cc: secdir@ietf.org <secdir@ietf.org>; iesg@ietf.org <iesg@= ietf.org>; draft-ietf-ecrit-data-only-ea.all@ietf.org <draft-ietf-ecr= it-data-only-ea.all@ietf.org>
Subject: Re: Secdir review of draft-ietf-ecrit-data-only-ea-18
 
Hi Charlie

Thanks for the review, I appreciate it.

The introduction section has this text
   Data-only emergency calls are similar to regula=
r emergency calls in=0A=
   the sense that they require the emergency indications, emergency call=0A=
   routing functionality and may even have the same location=0A=
   requirements.  However, the communication interaction will not lead=0A=
   to the exchange of interactive media, that is, Real-Time Protocol=0A=
   packets, such as voice, video data or real-time text.=0A=
=0A=
   ...=0A=
=0A=
   This document describes a method of including a CAP message in a SIP=0A=
   transaction by defining it as a block of "additional data" as =
defined=0A=
   in [RFC7852].  The CAP messa=
ge is included either by value (the CAP=0A=
   message is in the body of the message, using a CID) or by reference=0A=
   (a URI is included in the message, which when dereferenced returns=0A=
   the CAP message).  The additional data mechanism is also used to send=0A=
   alert specific data beyond that available in the CAP message.  This=0A=
   document also describes how a SIP MESSAGE [RFC3428] transaction can=0A=
   be used to send a data-only call.


This says that this document describes how to send an emergency c= all when there is not two way interactive media (voice, video and/or text),= and it says that the way you do that is to send a SIP MESSAGE, with a CAP = message pointed to by a Call-Info header.

That text seems very clear to me, and yet you didn=92t read what we ho= ped into what we wrote.  I would really like to fix this, but I=92m at= a loss to understand what I need to do.

I=92ll improve the acronym stuff.


On Aug 24, 2019, at 3:53 PM, Charlie Kaufman <charliekaufman@outlook.com> wrote:

I have reviewed this document as part of the security directorate's on= going effort to review all IETF documents being processed by the IESG. = ; These comments were written primarily for the benefit of the security are= a directors.  Document editors and WG chairs should treat these comments just like any other last call comments.=

This document defines a new MIME type: 'application/EmergencyCallData.= cap+xml' for use primarily by sensors to send alert messages to emergen= cy services providers. It also defines a new Emergency Call Data Type: 'cap= ' in order to embed this data efficiently in a SIP transaction. I saw no new security issues beyond those already no= ted for the protocols carrying these messages.

I do have some editorial suggestions:

There is a lot of context that the authors assumed any reader would ha= ve that could have been stated in the introduction. I believe from context = that the purpose of this new MIME type is to support simple (IoT) sensors t= hat don't want to implement a more heavyweight protocol, but I don't believe that was stated anywhere.

I got the impression that the functionality provided could have been d= one with existing protocols by sending the CAP message over a SIP session, = but that doing so would place an unnecessary burden on simple (IoT) sensors= , and that this protocol would be easier for such sensors to implement for the limited cases such sensors ne= ed to deal with. If that's true, it should be stated. If not, the purpose o= f this protocol should be more clearly stated.

These acronyms were used but never defined:

SIP
CID
LoST

These acronyms were expanded, but not in an easy to find place:

Common Alerting Protocol (CAP)
Public Safety Answering Points (PSAPs)
Emergency Services Routing Proxy (ESRP)

It would be nice to include them in the terminology section, ideally w= ith a reference to the RFC where more information is available.

Typo:

p17 "security mechanism" -> "security mechanisms&quo= t;

 --Charlie

--_000_MWHPR04MB036724650A0D208BE4D22D58DFA20MWHPR04MB0367namp_-- From nobody Thu Aug 29 14:47:56 2019 Return-Path: X-Original-To: expand-draft-ietf-ecrit-data-only-ea.all@virtual.ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id D8BE912091B; Thu, 29 Aug 2019 14:47:53 -0700 (PDT) X-Original-To: xfilter-draft-ietf-ecrit-data-only-ea.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-ecrit-data-only-ea.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A589A120073 for ; Thu, 29 Aug 2019 14:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 EMkKa_ZVkcaG for ; Thu, 29 Aug 2019 14:47:50 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 9B9D412091B for ; Thu, 29 Aug 2019 14:47:49 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id w18so4444140qki.0 for ; Thu, 29 Aug 2019 14:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=odg6dpKij/LmHrS2Ds0OllMn7Rdvh+ENHikA91oO+zw=; b=GLFPvKfXicijOD6QoKr4vUOukryMV7rZ0nWi4wQIZE123TC22sb8bLj86sovlB0TF8 eTYzE/JLX1jF2Df45w/0/OjmnlXQZrQPIgvui0UpVNdJdnNrFvEM9LsQWU7NiudMPhE2 lAu1I/8Nd8cN7d6oBwtB2iPge5Qk2GCoUoxBUO2jrH7PHztcnG05noqIZMBF/SKY/xtS yT+MOC/lKZ0j9/vs0Az355eJajxcWsz3kDoCchNyICCHSMKI8qjhRtFn3Igp2JWeTJJO nn6M7evdKO9r0onKQkWZIRP3bP149YBJA7VNI6E3jF29SJdSySJ+N1USzwIFGlerCp4T WZrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=odg6dpKij/LmHrS2Ds0OllMn7Rdvh+ENHikA91oO+zw=; b=RGkfBElLB923FfPrSNG0tTd7w+sIhim0drs8XsvOKigDr4rh5JX7fe//ea38ibKGnu 6jpkJp8kSiN0GncP2XD4gXJ0vB74vtVQZOhEDP+Bo6ZjkuqCDOzuIP1r1xOmQJpyg3Z5 fWg9QZfRK3RqoudK7i/r4bd6dSopO7GmVXA6PzV71+qMZKmgV+a/+bw7jV/flCEWmD0O E8BiNTLcVLdZobAV6QkXJsX0a3Hg9mTlm7zAC8UAo6Si7nEqCTCGGQUU75EPj0VtZ9mV 01lEJCf/Y0xieavIWEA/4Lz66e/JwQ7VigxF+y80M2YUp2dAKjrijmm1Nby5FPsDlChq IA1Q== X-Gm-Message-State: APjAAAUpvUX57cvpXa6CvqYC6WjKuNwsGVgKovK1AuokpzjySJ2CoCKZ wB9S2dL8TULELvHlj4cmjNtfgQ== X-Google-Smtp-Source: APXvYqx6RkdYwpPngDSyxaNuClliKzu+fPVzNFft/+uFQHx951tNpcpXw+5Tzhah6lZ8skdVORo+aA== X-Received: by 2002:a37:4a0b:: with SMTP id x11mr12078508qka.395.1567115268455; Thu, 29 Aug 2019 14:47:48 -0700 (PDT) Received: from brians-mbp-2388.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id r189sm1875773qkc.60.2019.08.29.14.47.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Aug 2019 14:47:47 -0700 (PDT) From: Brian Rosen Message-Id: <1D728931-DCCE-4A87-A247-A4A7FE1D8BE7@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_93D6D405-21E2-400A-84BF-6D9B1923FE1F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 29 Aug 2019 17:47:45 -0400 In-Reply-To: Cc: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-ecrit-data-only-ea.all@ietf.org" To: Charlie Kaufman References: X-Mailer: Apple Mail (2.3445.104.11) Resent-From: Resent-To: br@brianrosen.net, hgs+ecrit@cs.columbia.edu, hannes.tschofenig@arm.com, rg+ietf@coretechnologyconsulting.com, allison.mankin@gmail.com, roger.marshall@comtechtel.com, barryleiba@computer.org, adam@nostrum.com, aamelnikov@fastmail.fm, Allison Mankin , draft-ietf-ecrit-data-only-ea@ietf.org, ecrit@ietf.org Resent-Message-Id: <20190829214753.D8BE912091B@ietfa.amsl.com> Resent-Date: Thu, 29 Aug 2019 14:47:53 -0700 (PDT) Archived-At: Subject: Re: [Ecrit] Secdir review of draft-ietf-ecrit-data-only-ea-18 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 21:47:54 -0000 --Apple-Mail=_93D6D405-21E2-400A-84BF-6D9B1923FE1F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It=E2=80=99s new functionality. RFC6881 defines an interactive = emergency call that uses SIP INVITE. It does not have a CAP message. = This document defines a non-interactive (in the real time media sense) = call that uses SIP MESSAGE and includes the CAP message. To get CAP into any SIP transaction, you put it in.a =E2=80=98body=E2=80=99= which is MIME encoded. So the layering is: SIP MESSAGE bodypart MIME CAP Brian > On Aug 29, 2019, at 5:17 PM, Charlie Kaufman = wrote: >=20 > My confusion had to do with whether this is adding new functionality = or whether this is a profiling of existing functionality to enable a = lightweight interaction. For example, is it possible to send a CAP = message within a SIP transaction when there is going to follow = interactive two way media in the existing protocol? If so, this could = have been done with the previous protocol just by ending after the first = exchange. If not, this is something that couldn't have been done before = and this is new functionality (and I would wonder why the old protocol = did not allow this). >=20 > My confusion might be based on my lack of understanding of the = layering of CAP, SIP, and MIME, and it could be that anyone with a = legitimate reason to read this document would not be confused. >=20 > --Charlie >=20 > p.s. Apologies for the formatting. I'm using Outlook's web interface, = which tends to be overly clever and mess things up. >=20 > Sent from Outlook >=20 > From: Brian Rosen > Sent: Monday, August 26, 2019 1:34 PM > To: Charlie Kaufman > Cc: secdir@ietf.org ; iesg@ietf.org ; = draft-ietf-ecrit-data-only-ea.all@ietf.org = > Subject: Re: Secdir review of draft-ietf-ecrit-data-only-ea-18 > =20 > Hi Charlie >=20 > Thanks for the review, I appreciate it. >=20 > The introduction section has this text > Data-only emergency calls are similar to regular emergency calls in > the sense that they require the emergency indications, emergency = call > routing functionality and may even have the same location > requirements. However, the communication interaction will not lead > to the exchange of interactive media, that is, Real-Time Protocol > packets, such as voice, video data or real-time text. >=20 > ... >=20 > This document describes a method of including a CAP message in a = SIP > transaction by defining it as a block of "additional data" as = defined > in [RFC7852 ]. The CAP = message is included either by value (the CAP > message is in the body of the message, using a CID) or by reference > (a URI is included in the message, which when dereferenced returns > the CAP message). The additional data mechanism is also used to = send > alert specific data beyond that available in the CAP message. This > document also describes how a SIP MESSAGE [RFC3428 = ] transaction can > be used to send a data-only call. >=20 >=20 > This says that this document describes how to send an emergency call = when there is not two way interactive media (voice, video and/or text), = and it says that the way you do that is to send a SIP MESSAGE, with a = CAP message pointed to by a Call-Info header. >=20 > That text seems very clear to me, and yet you didn=E2=80=99t read what = we hoped into what we wrote. I would really like to fix this, but I=E2=80= =99m at a loss to understand what I need to do. >=20 > I=E2=80=99ll improve the acronym stuff. >=20 >=20 >> On Aug 24, 2019, at 3:53 PM, Charlie Kaufman = > wrote: >>=20 >> I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. >>=20 >> This document defines a new MIME type: = 'application/EmergencyCallData.cap+xml' for use primarily by sensors to = send alert messages to emergency services providers. It also defines a = new Emergency Call Data Type: 'cap' in order to embed this data = efficiently in a SIP transaction. I saw no new security issues beyond = those already noted for the protocols carrying these messages. >>=20 >> I do have some editorial suggestions: >>=20 >> There is a lot of context that the authors assumed any reader would = have that could have been stated in the introduction. I believe from = context that the purpose of this new MIME type is to support simple = (IoT) sensors that don't want to implement a more heavyweight protocol, = but I don't believe that was stated anywhere. >>=20 >> I got the impression that the functionality provided could have been = done with existing protocols by sending the CAP message over a SIP = session, but that doing so would place an unnecessary burden on simple = (IoT) sensors, and that this protocol would be easier for such sensors = to implement for the limited cases such sensors need to deal with. If = that's true, it should be stated. If not, the purpose of this protocol = should be more clearly stated. >>=20 >> These acronyms were used but never defined: >>=20 >> SIP >> CID >> LoST >>=20 >> These acronyms were expanded, but not in an easy to find place: >>=20 >> Common Alerting Protocol (CAP) >> Public Safety Answering Points (PSAPs) >> Emergency Services Routing Proxy (ESRP) >>=20 >> It would be nice to include them in the terminology section, ideally = with a reference to the RFC where more information is available. >>=20 >> Typo: >>=20 >> p17 "security mechanism" -> "security mechanisms" >>=20 >> --Charlie --Apple-Mail=_93D6D405-21E2-400A-84BF-6D9B1923FE1F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 It=E2=80=99s new functionality.  RFC6881 defines an = interactive emergency call that uses SIP INVITE.  It does not have = a CAP message.  This document defines a non-interactive (in the = real time media sense) call that uses SIP MESSAGE and includes the CAP = message.

To get CAP = into any SIP transaction, you put it in.a =E2=80=98body=E2=80=99 which = is MIME encoded.  So the layering is:
SIP = MESSAGE
bodypart MIME
= CAP

Brian

On Aug 29, 2019, at 5:17 PM, = Charlie Kaufman <charliekaufman@outlook.com> wrote:

My = confusion had to do with whether this is adding new functionality or = whether this is a profiling of existing functionality to enable a = lightweight interaction. For example, is it possible to send a CAP = message within a SIP transaction when there is going to follow = interactive two way media in the existing protocol? If so, this could = have been done with the previous protocol just by ending after the first = exchange. If not, this is something that couldn't have been done before = and this is new functionality (and I would wonder why the old protocol = did not allow this).

My = confusion might be based on my lack of understanding of the layering of = CAP, SIP, and MIME, and it could be that anyone with a legitimate reason = to read this document would not be confused.

--Charlie

p.s. = Apologies for the formatting. I'm using Outlook's web interface, which = tends to be overly clever and mess things up.

Sent from Outlook

From: Brian Rosen <br@brianrosen.net>
Sent: Monday, August 26, 2019 = 1:34 PM
To: Charlie Kaufman <charliekaufman@outlook.com>
Cc: secdir@ietf.org <secdir@ietf.org>; iesg@ietf.org <iesg@ietf.org>; draft-ietf-ecrit-data-only-ea.all@ietf.org <draft-ietf-ecrit-data-only-ea.all@ietf.org>
Subject: Re: Secdir review of = draft-ietf-ecrit-data-only-ea-18
 
Hi Charlie
Thanks for the review, I appreciate = it.

The = introduction section has this text
   Data-only emergency calls are similar to regular =
emergency calls in
   the sense that they require the emergency indications, emergency call
   routing functionality and may even have the same location
   requirements.  However, the communication interaction will not lead
   to the exchange of interactive media, that is, Real-Time Protocol
   packets, such as voice, video data or real-time text.

   ...

   This document describes a method of including a CAP message in a SIP
   transaction by defining it as a block of "additional data" as defined
   in [RFC7852].  The CAP message is included either by value =
(the CAP
   message is in the body of the message, using a CID) or by reference
   (a URI is included in the message, which when dereferenced returns
   the CAP message).  The additional data mechanism is also used to send
   alert specific data beyond that available in the CAP message.  This
   document also describes how a SIP MESSAGE [RFC3428] =
transaction can
   be used to send a data-only call.


This says that this document describes how to send an = emergency call when there is not two way interactive media (voice, video = and/or text), and it says that the way you do that is to send a SIP = MESSAGE, with a CAP message pointed to by a Call-Info header.

That text seems very = clear to me, and yet you didn=E2=80=99t read what we hoped into what we = wrote.  I would really like to fix this, but I=E2=80=99m at a loss = to understand what I need to do.

I=E2=80=99ll improve the acronym = stuff.


On Aug = 24, 2019, at 3:53 PM, Charlie Kaufman <charliekaufman@outlook.com> wrote:

I have reviewed this document as part of the = security directorate's ongoing effort to review all IETF documents being = processed by the IESG.  These comments were written primarily for = the benefit of the security area directors.  Document editors and = WG chairs should treat these comments just like any other last call = comments.

This = document defines a new MIME type: = 'application/EmergencyCallData.cap+xml' for use primarily by sensors to = send alert messages to emergency services providers. It also defines a = new Emergency Call Data Type: 'cap' in order to embed this data = efficiently in a SIP transaction. I saw no new security issues beyond = those already noted for the protocols carrying these messages.

I do have some editorial = suggestions:

There is a lot of context that the authors assumed any reader = would have that could have been stated in the introduction. I believe = from context that the purpose of this new MIME type is to support simple = (IoT) sensors that don't want to implement a more heavyweight protocol, = but I don't believe that was stated anywhere.

I got the impression that the = functionality provided could have been done with existing protocols by = sending the CAP message over a SIP session, but that doing so would = place an unnecessary burden on simple (IoT) sensors, and that this = protocol would be easier for such sensors to implement for the limited = cases such sensors need to deal with. If that's true, it should be = stated. If not, the purpose of this protocol should be more clearly = stated.

These = acronyms were used but never defined:

SIP
CID
LoST

These acronyms were expanded, but not in an easy to find = place:

Common = Alerting Protocol (CAP)
Public Safety Answering Points = (PSAPs)
Emergency Services Routing Proxy (ESRP)

It would be nice to = include them in the terminology section, ideally with a reference to the = RFC where more information is available.

Typo:

p17 "security mechanism" -> = "security mechanisms"

 --Charlie

= --Apple-Mail=_93D6D405-21E2-400A-84BF-6D9B1923FE1F-- From nobody Fri Aug 30 13:05:26 2019 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B73812096A; Fri, 30 Aug 2019 13:05:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , "Allison Mankin" , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156719552329.3322.12172959767625201831.idtracker@ietfa.amsl.com> Date: Fri, 30 Aug 2019 13:05:23 -0700 From: IETF Secretariat Archived-At: Subject: [Ecrit] Datatracker State Update Notice: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 20:05:24 -0000 IANA review state changed to "IANA - Not OK" Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/