[Ecrit] draft-ietf-ecall-07
"Drage, Keith (Nokia - GB)" <keith.drage@nokia.com> Thu, 19 May 2016 12:48 UTC
Return-Path: <keith.drage@nokia.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 05C6E12D1E8 for <ecrit@ietfa.amsl.com>; Thu, 19 May 2016 05:48:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 SEEHSDAzdP_K for <ecrit@ietfa.amsl.com>; Thu, 19 May 2016 05:48:43 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 96BDF12DA36 for <ecrit@ietf.org>; Thu, 19 May 2016 05:48:42 -0700 (PDT)
Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 427E5AC426F1B for <ecrit@ietf.org>; Thu, 19 May 2016 12:48:38 +0000 (GMT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4JCmeJ2010205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <ecrit@ietf.org>; Thu, 19 May 2016 12:48:40 GMT
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u4JCmdxr010463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <ecrit@ietf.org>; Thu, 19 May 2016 14:48:40 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.13]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 19 May 2016 14:48:39 +0200
From: "Drage, Keith (Nokia - GB)" <keith.drage@nokia.com>
To: "ecrit@ietf.org" <ecrit@ietf.org>
Thread-Topic: draft-ietf-ecall-07
Thread-Index: AdGxzMOa1jkAyUrdRtWpysRGemwi6w==
Date: Thu, 19 May 2016 12:48:40 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8BADEF7E85@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.38]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ecrit/4lVcM04rewn0H1GBMyS4Vcui-AY>
Subject: [Ecrit] draft-ietf-ecall-07
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: Thu, 19 May 2016 12:48:45 -0000
I did another read through of this document last night, and had the following comments. I have not reviewed the entire document. Note that this does not supercede any of the comments made in the last few days: 1) s. 2, 1st para: ecall in 3GPP is a 3GPP emergency call, and while there are some similarities, 3GPP emergency call does not fully comply with either RFC 6443 or RFC 6881. I am also not sure the references are relevant to the purpose of the draft in any case. 2) s. 2, 3rd and 4th para: These paragraphs seem to be going beyond document scope, and into a wish list. I suggest both these paragraphs are deleted. 3) s. 3, 4th paragraph: An eCall can be either user-initiated or automatically triggered. Automatically triggered eCalls indicate a car crash or some other serious incident and carry a greater presumption of risk of injury. Manually triggered eCalls might be reports of serious hazards and are likely to require a different response than an automatically triggered eCall. Manually triggered eCalls are also more likely to be false (e.g., accidental) calls and so might be subject to different operational handling by the PSAP. The distinction between seriousness and impact of manual versus automatic is highly subjective, and will depend on the underlying philosophy of the administration in how it handles what it regards as false alerts, which differs substantially from administration to administration. 4) s. 3, 5th para: As part of this work, the European Telecommunications Standards Institute (ETSI) [SDO-ETSI] has published a Technical Report titled "Mobile Standards Group (MSG); eCall for VoIP" [MSG_TR] that presents findings and recommendations regarding support for eCall in an all-IP environment. This somehow implies that the contents of this document are valid for the interpretation of the draft. Vewry little of the work has migrated into the stage 1 in 3GPP, and the other groups in 3GPP are working directly from the stage 1 description, not from the ETSI work. 5) s. 3 last para: A transition period will exist during which time the various entities involved in initiating and handling an eCall might support next- generation eCall, legacy eCall, or both. This transition period might last several years or longer. The issue of migration/co- existence during the transition period is very important but is outside the scope of this document. The ETSI TR "Mobile Standards Group (MSG); eCall for VoIP" [MSG_TR] discusses these issues in Clause 7. I have not found any statements that support the concept of a transition in any of the documents I have read. The 3GPP stage 1 requires both UEs and PSAPs to support both data transfer mechanisms. 6) s. 3 general Some statement should be made in this section about the need for the UE and the PSAP to support both mechanisms within SIP, as required by the stage 1, as the 3GPP emergency network does not provide any data interworking, only signalling interworking. Interworking SIP to CS domain, any attached body to a SIP message will be discarded. 7) s. 4 reference to 22.101, and s. 18.1. This document carries no provisions needed to implement this document, and therefore it should not be a normative reference. Further the reference should be to release 14 and later. The latest version of all releases of 3GPP documents are still valid documents for that release. 8) s. 4. Is considerably out of data in regard to the current version of 22.101. This appears to be a summary of the CS requirements before the IMS changes were made. 9) s. 6 last para. This document registers new service URN children within the "sos" subservice. These URNs provide the mechanism by which an eCall is identified, and differentiate between manually and automatically triggered eCalls (which can be subject to different treatment, depending on policy). The two service URNs are: urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual The URN does not identify an ecall. It identifies the resource to which the ecall needs to be directed. To explain further, the sos URN does not identify an emergency call, it identifies the resource needed to answer the emergency call, which is why we have a separate Resource-Priority namespace "esnet". 10) s.7 Europe does not use the term ESInet. That term is North America, and possibly USA, specific. It might be more appropriate to use terminology from the ETSI M483 group if this text is needed at all. 11) s.8 In regard to test calls, I think some statement should be made about what they actually test. Using this URN would certainly not test the emergency call handling capabilities of either the network or the UE. Does it test all data transfer capabilities (including the CS). Why do we need a URN rather than just the same number as is used in the CS domain? 12) s.9 Future enhancements are desired to enable the PSAP to send other requests to the vehicle, such as locking or unlocking doors, sounding the horn, flashing the lights, starting a video stream from on-board cameras (such as rear focus or blind-spot), etc. Do you have a reference for this, or is it speculative thinking? I do not think the mechanisms proposed in this draft are suitable for transferring a video stream, so even if provided, are they part of ecall, or just part of the standard emergency call. Maybe the only ecall responsibility is to indicate the existence of these? I'd note that extending beyond the existing CS domain capability is not required at the moment by the 3GPP stage 1. I think we all acknowledge that all and any data available in the car might be candidates for transfer to the PSAP, but it is not clear whether this is part of ecall, or whether it is part of the additional media beyond voice already available as part of 3GPP emergency call. Certainly there is a limit on the amount of data that can be transferred using the mechanisms currently in this draft, beyond which the QoS of the signalling channel will become inappropriate. 13) s.9 & s.13 It is not clear to me which elements correspond to the existing MSD defined by CEN, and which have been defined over the top. Firstly I think all data that is defined by CEN should carry an appropriate CEN reference, because the UE needs to support both, and it should be the same data that is transferred in this. That should occur either in one of these sections, or in a new separate section. Further, if information does go over the top of the existing CEN definition, this needs additional review and possibly postponement to a later version, as this is not required by the current 3GPP stage 1. 14) s.14.3 A call-back from a PSAP incurs additional risk, since the current mechanisms are not ideal for verifying that such a call is indeed a call-back from a PSAP in response to an emergency call placed by the IVS. See the discussion in Section 11 and the PSAP Callback document [RFC7090]. I do not understand why call-back is being referred to here. Can you explain? Regards Keith Drage
- [Ecrit] draft-ietf-ecall-07 Drage, Keith (Nokia - GB)
- Re: [Ecrit] draft-ietf-ecall-07 Randall Gellens