Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15
Christer Holmberg <christer.holmberg@ericsson.com> Tue, 18 October 2016 13:38 UTC
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0F8129A5D for <ecrit@ietfa.amsl.com>; Tue, 18 Oct 2016 06:38:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Qdg87FM_8-dS for <ecrit@ietfa.amsl.com>; Tue, 18 Oct 2016 06:38:44 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 DFFC41294C6 for <ecrit@ietf.org>; Tue, 18 Oct 2016 06:38:43 -0700 (PDT)
X-AuditID: c1b4fb2d-5b107980000009f7-a9-580625e1e05f
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id 0F.A7.02551.1E526085; Tue, 18 Oct 2016 15:38:41 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.90]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0319.002; Tue, 18 Oct 2016 15:38:40 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Ivo Sedlacek <ivo.sedlacek@ericsson.com>, Randall Gellens <rg+ietf@randy.pensive.org>, "ecrit@ietf.org" <ecrit@ietf.org>
Thread-Topic: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15
Thread-Index: AQHSKM9pnC2aMUPzqUuYRM5JMx1G9qCt+/AAgABO/YA=
Date: Tue, 18 Oct 2016 13:38:40 +0000
Message-ID: <D42C016C.11565%christer.holmberg@ericsson.com>
References: <p06240605d42aaac123bb@[99.111.97.136]> <AM5PR0701MB2468193301B56352CE85005DE5D30@AM5PR0701MB2468.eurprd07.prod.outlook.com>
In-Reply-To: <AM5PR0701MB2468193301B56352CE85005DE5D30@AM5PR0701MB2468.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.9.160926
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <1F93B6054FB18545BD82875BE36455E5@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2J7iO5DVbYIg1XPrSwaFz1ltfj+vIvR gcljyZKfTB5b7zxmCWCK4rJJSc3JLEst0rdL4MqYe/AZW8FEl4p1934wNzD2m3YxcnJICJhI /P/0ir2LkYtDSGA9o8Ty5ocsEM5iRomDO9YDZTg42AQsJLr/aYM0iAjUSezYtYcVxBYWsJOY 9XMyC0TcXuLr95fMELaVRF/rJrA4i4CqRMfqT8wgY3gFrCXO90ZBjO8CGv+7nw2khlMgUWJR x0ewmYwCYhLfT61hArGZBcQlbj2ZzwRxqIDEkj3nmSFsUYmXj/+xgswUFdCTWHM/DCKsKPHx 1T5GiFY9iRtTp7BB2NYSJ04+YYawtSWWLXwNZvMKCEqcnPmEZQKj2Cwk22YhaZ+FpH0WkvZZ SNoXMLKuYhQtTi0uzk03MtZLLcpMLi7Oz9PLSy3ZxAiMqoNbfuvuYFz92vEQowAHoxIPb8JN lggh1sSy4srcQ4wSHMxKIrxXVdgihHhTEiurUovy44tKc1KLDzFKc7AoifOarbwfLiSQnliS mp2aWpBaBJNl4uCUamDU0FZbsOcaV7nnx59Lz08PU/393k7R9dBME87inmopreydjMu1Lvt7 xUryr0ib7276J4fn6hk5nn3xS3s5W5fOill74Wh664YD6WpRUpUr/Sfw5SzJcHLL7GNjv9IZ 9Pxm+Xm+t3wLDqaL3r4e8kGi79eN/G8tLE6XeUp6blbPXfNvpcjklXxKLMUZiYZazEXFiQAr qQutpgIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/LPcUkFrBoRmq18ueUAPsqDZcrsQ>
Subject: Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Oct 2016 13:38:46 -0000
Hi, Regarding indicating the type of multipart (mixed, alternative etc), I agree with Ivo. Unfortunately RFC 6086 doesn¹t normatively define the type either (in the examples multipart/mixed is used, though), why I think it¹s even more important to do it in draft-ecall. Regards, Christer On 18/10/16 15:02, "Ecrit on behalf of Ivo Sedlacek" <ecrit-bounces@ietf.org on behalf of ivo.sedlacek@ericsson.com> wrote: >Hello, > >first of all, I am participating in 3GPP CT1 meeting this week and I have >not have time to review changes between -015 and -018 properly. Can we >shift the deadline to next week? > >I am OK with resolution of ISSUE 1, ISSUE 3, ISSUE 8, ISSUE 13, ISSUE 15, >ISSUE 16, ISSUE 17, ISSUE 19. > >On the remaining issues: > >> > ISSUE 2: >> > >> > section 3 - level of technical detail of the last paragraph of >> > section 3 does not fit with level of technical detail of the >>remaining >> > text of section 3. >> >> Intermediate paragraphs were added in version 17. > >I still believe that section 3 contains different types of information: >Type1: generic overview of the eCall requirements, existing solutions, ... >Type2: information about the draft > >It would be better to split those to separate sections. > >> > ISSUE 4: >> > >> > section 4, " This document registers the 'application/ >> > emergencyCallData.eCall.MSD+per' MIME Content-Type to enable the >>MSD >> > to be carried in SIP." >> > >> > There is no MIME Content-Type registry. "MIME Content-Type" -> "MIME >>type" >> > >> > Same in other places of the document. >> >> Corrected "content type" to "media type". > >I can still see a few occurences of "content type" in -018 - e.g. > >--------- > Security considerations: This ****content type**** is designed to >carry > vehicle and incident-related data during an emergency call. This > data contains personal information including vehicle VIN, > location, direction, etc. Appropriate precautions need to be > taken to limit unauthorized access, inappropriate disclosure to > third parties, and eavesdropping of this information. In general, > it is acceptable for the data to be unprotected while briefly in > transit within the Mobile Network Operator (MNO); the MNO is > trusted to not permit the data to be accessed by third parties. > Sections 7 and Section 8 of [RFC7852] contain more discussion. >--------- >and >--------- > The metadata/control block is designed for use with pan-European > eCall and also eCall-like systems (i.e., in other regions), and has > extension points. Note that eCall-like systems might define their > own vehicle data blocks, and so might need to register a new INFO > package to accomodate the new data ****content type**** and the >metadata/ > control object. >--------- >and >-------- > This ****content type**** carries metadata and control >information and > requests, such as from a Public Safety Answering Point (PSAP) > to an In-Vehicle System (IVS) during an emergency call. >-------- > >> > ISSUE 6: >> > >> > section 6 - "An MSD or a metadata/control block is always enclosed >>in >> > a multipart >> > body part (even if it would otherwise be the only body part in the >> > SIP message)." - which multipart MIME type is meant? >> > multipart/mixed or multipart/alternative or .... >> >> We do not need to specify that in this text. > >IMO, we need to. Else, the UA can provide multipart/mixed while PSAP >expects multipart/alternative. > >> > ISSUE 7 >> > >> > section 6 - "The IVS then attaches an updated MSD to a SIP >> > INFO request and sends it within the dialog." - what is meant by >> > "attaching MSD to SIP INFO request"? >> >> I think that's made abundantly clear in the multiple earlier instances >>in the >> same section that say "as a MIME body part". > >I do not really know what "attach body to SIP request" means. Likely, >other readers will not know it either. > >A reference to a section defining how to "attach body to SIP request" >would help. > > >> > ISSUE 9 >> > >> > section 9 - what is "SIP status message"? >> >> I do not see "SIP status message" anywhere in the document. > >It was in -015 section 9 but it looks like it was already resolved in -18. > > >> > ISSUE 10 >> > >> > " >> > For >> > example, if a PSAP is unable to accept an eCall (e.g., due to >> > overload or too many calls from the same location), it can reject >>the >> > INVITE. Since a metadata/control object is also included in the >>SIP >> > response that rejects the call, the IVS knows if the PSAP received >> > the MSD, and can inform the vehicle occupants that the PSAP >> > successfully received the vehicle location and information but >>can't >> > talk to the occupants at that time." - this prevents persons in >> > the car from getting emergency service of the PSAP using other means >> > (e.g. using circuit switched network). Possibility for DOS attack. >> >> If the PSAP is overloaded (e.g., there is a very large multi-vehicle >> incident, or another large-scale emergency incident), then there are >>likely >> to be multiple simultaneous eCall attempts. The document does not in >>any way >> dictate or mandate PSAP response. PSAPs are free to respond as they >>choose. >> E.g., a PSAP can accept eCalls and add them to a queue, a PSAP can >>reject an >> eCall and include an ack with "received=false", a PSAP can reject an >>eCall >> and include an ack with "received=true". Doing the latter indicates >>that the >> PSAP has received the MSD and hence is aware of the incident. > >How can the UA be sure that such response was sent by PSAP and not by an >attacker, located somewhere between UA and PSAP? > >Any SIP entity which happens to be in the path of the emergency call >INVITE request can generate a 600 (Busy Everywhere), 486 (Busy Here), >and 603 (Decline) response and populate it with a particular body. > >It is at least a security risk and it needs to be documented. > >> > ISSUE 11 >> > >> > "The body for an emergencyCallData.eCall.MSD info package is a >> > multipart body." - which multipart MIME type is meant? >> > multipart/mixed or multipart/alternative or .... >> >> We do not need to get into that level of detail in this text. > >IMO, we need to. Else, the UA can provide multipart/mixed while PSAP >expects multipart/alternative. > >> > ISSUE 14 >> > >> > "while others can be >> > expected to carry an occasional request" - meaning of >>"occasional" >> > can be whatever, it depends on perspective of the user >> > - once per milisecond, once per second, once per minute, once per >>hour >> > or once per day? >> >> Other text makes it clear that a request for an updated MSD is >>generally sent >> upon manual request of a PSAP call taker who suspects vehicle state may >>have changed. > >A statement that the request is expected to be triggered by manual action >of the PSAP call taker is good, so I suggest to add it to this section >too as expert reviewer will read it. > >> > >> > ISSUE 18 >> > >> > Accept in Figure 10 is not correct - INFO response is not expected >> > to contain body. >> >> Fixed, thanks for catching this. > >in -18, I can still see Accept with multipart/mixed in the INFO request >in Figure 10. > >IMO, this is wrong as we do NOT expect a body in INFO response. Yes, >there will be a body in subsequent INFO request sent in opposite >direction, but that's not impacted by Accept in first INFO request. > >> > >> > ISSUE 20 >> > >> > examples contain a value of schemaLocation parameter which is not >> > aligned with https://www.w3.org/TR/xmlschema-0/#schemaLocation >> > stating "The schemaLocation attribute value consists of one or more >> > pairs of URI references, separated by white space. " >> > >> > xsi:schemaLocation= >> > "urn:ietf:params:xml:ns:EmergencyCallData:control" >> >> Fixed. > >I can see in -18, that you chose to remove the information about schema >location from the XML examples. >That's OK with me. > >However, then you can also remove the following as it is not needed any >more > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > >Kind regards > >Ivo Sedlacek > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit
- [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 Ivo Sedlacek
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Randall Gellens
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Ivo Sedlacek
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Christer Holmberg
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Randall Gellens
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Christer Holmberg
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Ivo Sedlacek
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Randall Gellens
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Az Mankin
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Christer Holmberg
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Ivo Sedlacek
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Ivo Sedlacek
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Randall Gellens