Re: [Ecrit] ECRIT Interim meeting - June

["Drage, Keith (Nokia - GB)" <[e-mail]>]

Are you even bothering to read the mailing list - give me an assessment of the draft editor's response to all comments over the last month!

I have seen zero response from the draft editor on any of the comments I have made.

Some of these have been part of existing threads (comments on INFO usage and service URN semantics - so please do not forget my comments there), but there is two major sets of comments made on 19th May, which follow this message to ensure they are not lost.

Regards

Keith

Set 1


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?

Set 2


I did a reread of the INFO RFC last night in respect of the above draft, and came to the following conclusions.



1)    Any usage of the INFO method requires a full Info package definition. While there are various mentions of legacy usage, the draft is not trying to follow that direction, and in any case I am not convinced new registrations of relevant usage would be allowed down that route. So if the draft is to attempt to use the INFO method, it should formally define that method.



2)    The INFO RFC lays down clear instructions for the reviewer of the INFO package definition before it can be registered. In my view the current ecrit-ecall document would not pass that review.



3)    The INFO RFC makes no reference to transfer of data outside of the INFO method itself. My understanding is that the negotiation of the Info package within the Info-Package header field set to 'emergencyCallData.eCall' relates only to the data transferred in the INFO method using a conformant Info package definition. There therefore needs to be a discussion about what forms the negotiation mechanism for other information transferred, for example in the INVITE request, or other methods of the dialog, if such transfer is needed, and for it to be clearly documented.



4)    As indicated in 3), the INFO RFC does not expect data outside the Info package itself, and therefore nothing is stated there about the correlation of data between an application tagging things onto the methods of the dialog, and the application using the Info package.



5)    The INFO RFC allows for multiple Info packages to be used on the same dialog. There needs to be careful review to ensure that this capability is not compromised either in regard to the existing Info packages, or to new ones, particularly in regard to the assumed correlation between data in the Info package, and data transferred elsewhere in the dialog. I'd note that the draft would appear to sanction the inclusion of data in INFO methods belonging to entirely unrelated Info packages.


I would note that I am beginning to question whether there needs to be any transfer of data in the INVITE request. Transfer only within the INFO package after the response to the INVITE request is exchanged would still meet the 3GPP stage 1 requirements (see 22.101 release 14), and the whole document would be significantly simpler. None of the contents of the MSD is used for routeing the emergency call. This is without going into discussion about whether transfer using the signalling bearer, or some bearer negotiated using the SDP, is more appropriate.


From: Roger Marshall [mailto:[e-mail]]
Sent: 03 June 2016 17:52
To: Drage, Keith (Nokia - GB); [e-mail]
Subject: RE: ECRIT Interim meeting - June

Keith:
I think you mean that you want to see all of your comments addressed ahead of an updated draft, right?  I see comments being made and some responses.

If you have comments that you believe haven't been addressed as part of the list discussions, resend them.  Be sure to offer proposed text to what you believe may be deficiencies in the current draft.

-roger.

From: Drage, Keith (Nokia - GB) [mailto:[e-mail]]
Sent: Friday, June 03, 2016 9:45 AM
To: Roger Marshall; [e-mail]<mailto:[e-mail]>
Subject: RE: ECRIT Interim meeting - June

Can we see some response to the comments being made first.

This is a WG document, and is meant to reflect the consensus of the working group, and not the authors thoughts and considerations.

Keith

From: Ecrit [mailto:[e-mail]] On Behalf Of Roger Marshall
Sent: 03 June 2016 17:41
To: Roger Marshall; [e-mail]<mailto:[e-mail]>
Subject: Re: [Ecrit] ECRIT Interim meeting - June

Given a variety of factors, including individuals' availability, the chairs have decided to Not schedule an interim meeting at this time.  We look forward to seeing continued list discussion in order to work through the current issues, and it seems like progress is being made.  We also look forward to getting an updated draft soon, so that folks can see the proposed text changes being discussed.

Roger Marshall & Marc Linsner
ECRIT Chairs

From: Ecrit [mailto:[e-mail]] On Behalf Of Roger Marshall
Sent: Wednesday, June 01, 2016 4:04 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [Ecrit] ECRIT Interim meeting - June

ECRIT:
The work group needs to figure out how it can address some of the raised issues in order to make progress on draft-ietf-ecrit-ecall-07.

We've set up a doodle poll at the following link for next week:

http://doodle.com/poll/hnfhkvfgc7x6hesx

Please mark your best available times to discuss.  Bridge information will follow, once we have a timeslot identified.


Roger Marshall & Marc Linsner
ECRIT Chairs



NOTICE TO RECIPIENT: This email, including attachments, may contain information which is confidential, proprietary, attorney-client privileged and/or controlled under U.S. export laws and regulations and may be restricted from disclosure by applicable State and Federal law. Nothing in this email shall create any legal binding agreement between the parties unless expressly stated herein and provided by an authorized representative of Comtech Telecommunications Corp. or its subsidiaries. If you are not the intended recipient of this message, be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify us immediately by return email and permanently delete all copies of the original email and any attached documentation from any computer or other media.