Subject: Re: [Ecrit] New Liaison Statement, "Reply LS on eCall support for the EU from IETF Ecrit WG"

From: Alissa Cooper <[email-masked]>
Date: Thu, 14 Jan 2016 06:14:28 -0800

Hi Ivo,

As I noted, I believe the assumption is that there are people participating in both groups and thus the current IETF drafts reflect those people’s expectations about what may arise out of 3GPP. Of course if the drafts become RFCs and it turns out that 3GPP’s requirements don’t match up, there’s always the option of doing bis drafts.

I’m just reflecting back what I believe the will of both this WG and 3GPP to be — as I said, the liaison statement doesn’t ask ECRIT to stop its work and wait, and it was my impression that WG participants here didn’t think that was necessary either. But if the WG consensus would point in the direction of waiting, that would be fine too.

Alissa

> On Dec 22, 2015, at 5:11 AM, Ivo Sedlacek <[email-masked]> wrote:
> 
> Hello,
> 
>> The plan is to continue progressing the drafts and for those who are involved in both to keep an eye out for potential areas where there might be a lack of harmonization. 
> 
> Won’t the drafts be soon published as RFCs? 
> 
> If so, how will that allow harmonization with the future 3GPP requirements?
> 
> Kind regards
> 
> Ivo Sedlacek
> 
> -----Original Message-----
> From: Ecrit [mailto:[email-masked]] On Behalf Of Alissa Cooper
> Sent: Friday, December 18, 2015 9:13 PM
> To: DRAGE, Keith (Keith)
> Cc: Ben Campbell; Marc Linsner; Liaison Statement Management Tool; [email-masked]; Barry Leiba; Emergency Context Resolution with Internet Technologies Discussion List
> Subject: Re: [Ecrit] New Liaison Statement, "Reply LS on eCall support for the EU from IETF Ecrit WG"
> 
> We’ve known for awhile now that the 3GPP work was going to be somewhat delayed compared to the IETF work. The plan is to continue progressing the drafts and for those who are involved in both to keep an eye out for potential areas where there might be a lack of harmonization. I think this is implicitly reflected in the liaison statement the WG received — it doesn’t ask the WG to stop what it’s doing.
> Alissa 
> 
>> On Dec 8, 2015, at 8:25 PM, DRAGE, Keith (Keith) <[email-masked]> wrote:
>> 
>> The underlying problem here is that SA2 has not yet done enough work (as in none) to see if the IETF drafts meet the 3GPP requirements. The SA2 study is critical to this.
>> 
>> Given that 3GPP usage is pretty much the only use case for these drafts...
>> 
>> Keith
>> 
>> -----Original Message-----
>> From: Ecrit [mailto:[email-masked]] On Behalf Of Liaison Statement Management Tool
>> Sent: 02 December 2015 18:17
>> To: Roger Marshall; Marc Linsner
>> Cc: Ben Campbell; Marc Linsner; Emergency Context Resolution with Internet Technologies Discussion List; [email-masked]; Barry Leiba
>> Subject: [Ecrit] New Liaison Statement, "Reply LS on eCall support for the EU from IETF Ecrit WG"
>> 
>> Title: Reply LS on eCall support for the EU from IETF Ecrit WG Submission Date: 2015-12-02 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1447/
>> 
>> From: "[email-masked]" <[email-masked]>
>> To: Marc Linsner <[email-masked]>, Roger Marshall <[email-masked]>
>> Cc: Barry Leiba <[email-masked]>,Marc Linsner <[email-masked]>,Ben Campbell <[email-masked]>,Alissa Cooper <[email-masked]>,Roger Marshall <[email-masked]>,Emergency Context Resolution with Internet Technologies Discussion List <[email-masked]>, Response Contacts: [email-masked] Technical Contacts: 
>> Purpose: In response
>> 
>> Referenced liaison: Liaison Statement on NG eCall support for the EU (https://datatracker.ietf.org/liaison/1412/)
>> 
>> Body: 
>> 1. Overall Description:
>> SA2 would like to thank IETF ECRIT for the incoming LS informing 3GPP of IETF work enabling eCall over IETF SIP. SA2 has agreed on a work item (enclosed) in SA2#111, see WID (S2-153654) "Evolution to and Interworking with eCall in IMS Stage2".
>> 
>> SA2 plans to start work on this topic at SA2#113 and finalize the work by May 2016. 
>> 
>> 2. Actions:
>> To IETF Ecrit WG group.
>> ACTION: 	TSG SA WG2 respectfully asks IETF ECRIT to take the above information into account. 
>> 
>> 3. Date of Next TSG-SA WG2 Meetings:
>> TSG-SA WG2 Meeting #113	25-29 January, 2016		St. Kitts
>> TSG-SA WG2 Meeting #114	11-15 April, 2016		Sophia Antipolis, FR
>> 
>> Attachments:
>> 
>>   S2-154463_was_154449_154138_LS_Reply_IETF_cl
>>   https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2015-12-02-3gpp-tsgsa-sa2-ecrit-reply-ls-on-ecall-support-for-the-eu-from-ietf-ecrit-wg-attachment-1.pdf
>> 
>>   S2-153654-ecall over IMS-r8
>>   https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2015-12-02-3gpp-tsgsa-sa2-ecrit-reply-ls-on-ecall-support-for-the-eu-from-ietf-ecrit-wg-attachment-2.pdf
>> 
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
>> 
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 14 Jan 2016 14:40:58 +0000

You are being very vague about the terminology you are using.

If by stop you mean the stopping the discussions within the working group, then nobody is asking for that.

If by stop you mean delay the publication request to IESG, then that should definitely occur, and I believe several posters have stated this.

There is no point in publishing this as an RFC until the response of a 3GPP network is known, as a 3GPP network is the only delivery mechanism for such a call. As such, I request again that no publication request is submitted for these documents until some work on the 3GPP side has occurred, and people are able to comment on the drafts based on the 3GPP requirements.

Keith

-----Original Message-----
From: Alissa Cooper [mailto:[email-masked]] 
Sent: 14 January 2016 14:14
To: Ivo Sedlacek
Cc: DRAGE, Keith (Keith); Ben Campbell; Marc Linsner; Liaison Statement Management Tool; [email-masked]; Barry Leiba; Emergency Context Resolution with Internet Technologies Discussion List
Subject: Re: [Ecrit] New Liaison Statement, "Reply LS on eCall support for the EU from IETF Ecrit WG"

Hi Ivo,

Alissa

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 14 Jan 2016 14:58:28 +0000

Which telecommunications network or IP network is car crash expected to work on?

Keith

-----Original Message-----
From: EXT Brian Rosen [mailto:[email-masked]] 
Sent: 14 January 2016 14:57
To: DRAGE, Keith (Keith)
Cc: Alissa Cooper; Ivo Sedlacek; Ben Campbell; Marc Linsner; Emergency Context Resolution with Internet Technologies Discussion List
Subject: Re: [Ecrit] New Liaison Statement, "Reply LS on eCall support for the EU from IETF Ecrit WG"

I strongly object to waiting.  The WG prevailed on authors to rework drafts ways that make the North American draft (“car-crash”) dependent on the eCall draft.  If we delay the eCall draft, we can’t publish the car-crash draft and that is a problem, since we need to implement it.

Brian

> On Jan 14, 2016, at 9:40 AM, DRAGE, Keith (Keith) <[email-masked]> wrote:
>

---

From: Brian Rosen <[email-masked]>
Date: Thu, 14 Jan 2016 10:06:18 -0500

> On Jan 14, 2016, at 9:57 AM, Brian Rosen <[email-masked]> wrote:
>

---

From: Brian Rosen <[email-masked]>
Date: Thu, 14 Jan 2016 10:08:29 -0500

NENA i3 ESInets from existing Telematics companies

Brian

> On Jan 14, 2016, at 9:58 AM, DRAGE, Keith (Keith) <[email-masked]> wrote:
>

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 14 Jan 2016 15:09:30 +0000

> There is no point in publishing this as an RFC until the response of a 3GPP network is known, as a 3GPP network is the only delivery mechanism for such a call. 
> As such, I request again that no publication request is submitted for these documents until some work on the 3GPP side has occurred, and people are able to comment on the drafts based on the 3GPP requirements.

I have the same view as Keith.

Kind regards

Ivo

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Thursday, January 14, 2016 8:41 AM
To: Alissa Cooper; Ivo Sedlacek
Cc: Ben Campbell; Marc Linsner; Emergency Context Resolution with Internet Technologies Discussion List
Subject: RE: [Ecrit] New Liaison Statement, "Reply LS on eCall support for the EU from IETF Ecrit WG"

Keith

-----Original Message-----
From: Alissa Cooper [mailto:[email-masked]] 
Sent: 14 January 2016 14:14
To: Ivo Sedlacek
Cc: DRAGE, Keith (Keith); Ben Campbell; Marc Linsner; Liaison Statement Management Tool; [email-masked]; Barry Leiba; Emergency Context Resolution with Internet Technologies Discussion List
Subject: Re: [Ecrit] New Liaison Statement, "Reply LS on eCall support for the EU from IETF Ecrit WG"

Hi Ivo,

Alissa

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 14 Jan 2016 15:11:04 +0000

Which __radio__ network is the car crash expected to work on?

Kind regards

Ivo

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Thursday, January 14, 2016 9:08 AM
To: DRAGE, Keith (Keith)
Cc: Ben Campbell; Marc Linsner; Emergency Context Resolution with Internet Technologies Discussion List
Subject: Re: [Ecrit] New Liaison Statement, "Reply LS on eCall support for the EU from IETF Ecrit WG"

Brian

---

From: Brian Rosen <[email-masked]>
Date: Thu, 14 Jan 2016 10:14:18 -0500

Most of these systems use existing 3G/4G network data channels I believe.  That part is proprietary and we don’t care.  The part that we’re dependent on is from the telematics company to the PSAP.  These systems have proprietary protocols from car to the telematics company and then standards based protocols from the telematics company to the PSAP.

Brian

> On Jan 14, 2016, at 10:11 AM, Ivo Sedlacek <[email-masked]> wrote:
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 14 Jan 2016 15:28:36 +0000

There are calling devices directly connected to NENA i3?

Keith

-----Original Message-----
From: EXT Brian Rosen [mailto:[email-masked]] 
Sent: 14 January 2016 15:08
To: DRAGE, Keith (Keith)
Cc: Ben Campbell; Emergency Context Resolution with Internet Technologies Discussion List; Marc Linsner
Subject: Re: [Ecrit] New Liaison Statement, "Reply LS on eCall support for the EU from IETF Ecrit WG"

Brian

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 14 Jan 2016 15:32:41 +0000

Hello,

> Most of these systems use existing 3G/4G network data channels I believe.  

So, basicall, you are saying that radio network of 3GPP operators will be used for transport of the eCall.... 

Assuming eCall is treated by regulators as other emergency calls, the regulators will make 3GPP operators responsible for routing eCalls.

Therefore, 3GPP needs to study how the impact on 3GPP operators (both on radio network and on SIP indrastructure) can be as minimal as possible. Based on the outcome of this study, the IETF draft might need changes....

Kind regards

Ivo Sedlacek

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, January 14, 2016 9:14 AM
To: Ivo Sedlacek
Cc: DRAGE, Keith (Keith); Ben Campbell; Marc Linsner; Emergency Context Resolution with Internet Technologies Discussion List
Subject: Re: [Ecrit] New Liaison Statement, "Reply LS on eCall support for the EU from IETF Ecrit WG"

Brian

---

From: Randall Gellens <[email-masked]>
Date: Thu, 14 Jan 2016 08:58:57 -0800

Hi Keith,

Brian is talking about North American telematics emergency calls, 
where the deployed base uses proprietary mechanisms between the 
vehicle and a service center, and then standard mechanisms from the 
service center to the PSAP.  For i3 (NG), such calls (between the 
service center and the PSAP) will use the mechanisms in the car-crash 
draft.

At 3:28 PM +0000 1/14/16, Keith (Keith) DRAGE wrote:

>  Cc: Ben Campbell; Emergency Context Resolution with Internet 
> Technologies Discussion List; Marc Linsner
>>  Cc: Alissa Cooper; Ivo Sedlacek; Ben Campbell; Marc Linsner; 
>> Emergency Context Resolution with Internet Technologies Discussion 
>> List
>>  I strongly object to waiting.  The WG prevailed on authors to 
>> rework drafts ways that make the North American draft 
>> ("car-crash") dependent on the eCall draft.  If we delay the eCall 
>> draft, we can't publish the car-crash draft and that is a problem, 
>> since we need to implement it.
>>
>>  Brian
>>
>>>  If by stop you mean the stopping the discussions within the 
>>> working group, then nobody is asking for that.
>>>
>>>  If by stop you mean delay the publication request to IESG, then 
>>> that should definitely occur, and I believe several posters have 
>>> stated this.
>>>
>>>  There is no point in publishing this as an RFC until the response 
>>> of a 3GPP network is known, as a 3GPP network is the only 
>>> delivery mechanism for such a call. As such, I request again that 
>>> no publication request is submitted for these documents until 
>>> some work on the 3GPP side has occurred, and people are able to 
>>> comment on the drafts based on the 3GPP requirements.
>>>
>>>  Keith
>>>
>>>  Cc: DRAGE, Keith (Keith); Ben Campbell; Marc Linsner; Liaison 
>>> Statement Management Tool; [email-masked]; Barry Leiba; 
>>> Emergency Context Resolution with Internet Technologies 
>>> Discussion List
>>>  As I noted, I believe the assumption is that there are people 
>>> participating in both groups and thus the current IETF drafts 
>>> reflect those people's expectations about what may arise out of 
>>> 3GPP. Of course if the drafts become RFCs and it turns out that 
>>> 3GPP's requirements don't match up, there's always the option of 
>>> doing bis drafts.
>>>
>>>  I'm just reflecting back what I believe the will of both this WG 
>>> and 3GPP to be - as I said, the liaison statement doesn't ask 
>>> ECRIT to stop its work and wait, and it was my impression that WG 
>>> participants here didn't think that was necessary either. But if 
>>> the WG consensus would point in the direction of waiting, that 
>>> would be fine too.
>   >>
>>>  Alissa
>>>
>>>>>  The plan is to continue progressing the drafts and for those 
>>>>> who are involved in both to keep an eye out for potential areas 
>>>>> where there might be a lack of harmonization.
>>>>
>>>>  Won't the drafts be soon published as RFCs?
>>>>
>>>>  Cc: Ben Campbell; Marc Linsner; Liaison Statement Management 
>>>> Tool; [email-masked]; Barry Leiba; Emergency Context 
>>>> Resolution with Internet Technologies Discussion List
>>>>  We've known for awhile now that the 3GPP work was going to be 
>>>> somewhat delayed compared to the IETF work. The plan is to 
>>>> continue progressing the drafts and for those who are involved 
>>>> in both to keep an eye out for potential areas where there might 
>>>> be a lack of harmonization. I think this is implicitly reflected 
>>>> in the liaison statement the WG received - it doesn't ask the WG 
>>>> to stop what it's doing.
>>>>  Alissa
>>>>
>>>>>  The underlying problem here is that SA2 has not yet done enough 
>>>>> work (as in none) to see if the IETF drafts meet the 3GPP 
>>>>> requirements. The SA2 study is critical to this.
>>>>>
>>>>>  Cc: Ben Campbell; Marc Linsner; Emergency Context Resolution 
>>>>> with Internet Technologies Discussion List; 
>>>>> [email-masked]; Barry Leiba
>>>>>  Title: Reply LS on eCall support for the EU from IETF Ecrit WG 
>>>>> Submission Date: 2015-12-02 URL of the IETF Web page: 
>>>>> https://datatracker.ietf.org/liaison/1447/
>>>>>
>>>>>  Cc: Barry Leiba <[email-masked]>,Marc Linsner 
>>>>> <[email-masked]>,Ben Campbell <[email-masked]>,Alissa 
>>>>> Cooper <[email-masked]>,Roger Marshall 
>>>>> <[email-masked]>,Emergency Context Resolution with 
>>>>> Internet Technologies Discussion List <[email-masked]>, 
>>>>> Response Contacts: [email-masked] Technical Contacts:
>>>>>  Purpose: In response
>>>>>
>>>>>  Referenced liaison: Liaison Statement on NG eCall support for 
>>>>> the EU (https://datatracker.ietf.org/liaison/1412/)
>>>>>
>>>>>  Body:
>>>>>  1. Overall Description:
>>>>>  SA2 would like to thank IETF ECRIT for the incoming LS 
>>>>> informing 3GPP of IETF work enabling eCall over IETF SIP. SA2 
>>>>> has agreed on a work item (enclosed) in SA2#111, see WID 
>>>>> (S2-153654) "Evolution to and Interworking with eCall in IMS 
>>>>> Stage2".
>>>>>

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
[M]any of the people in the arena here, you know, were
underprivileged anyway, so this is [chuckle] working very well
for them.
--Barbara Bush at the Houston Astrodome, commenting on the
  more than 20,000 evacuees from New Orleans housed there,
  September 5, 2005.

---

From: Brian Rosen <[email-masked]>
Date: Thu, 14 Jan 2016 13:01:27 -0500

These calls are NOT treated as emergency calls between the vehicle and the telematics center.  The underlying carrier is unaware of what the call and/or data represents.

Brian

> On Jan 14, 2016, at 10:32 AM, Ivo Sedlacek <[email-masked]> wrote:
> 
> Hello,
>

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 14 Jan 2016 18:10:33 +0000

But eCall INVITE has Request-URI set to an emergency URN, right? So, it is an *emergency* call and every *emergency* call regulation will apply to it, correct?

Kind regards

Ivo

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, January 14, 2016 12:01 PM
To: Ivo Sedlacek
Cc: DRAGE, Keith (Keith); Ben Campbell; Marc Linsner; Emergency Context Resolution with Internet Technologies Discussion List
Subject: Re: [Ecrit] New Liaison Statement, "Reply LS on eCall support for the EU from IETF Ecrit WG"

Brian

---

From: Brian Rosen <[email-masked]>
Date: Thu, 14 Jan 2016 13:24:55 -0500

Only on the call from the telematics provider to the PSAP.  

But let’s ignore this distinction, especially since what we WANT the telematics guys to do is to redirect the call to urn:service:sos and request the telematics operator as a 3rd party using a “Referred-By” header.  In that case, it would be an emergency call. But we already have “Additional Data” being sent, and car-crash just extends that.

Brian

> On Jan 14, 2016, at 1:10 PM, Ivo Sedlacek <[email-masked]> wrote:
>

---

From: James Winterbottom <[email-masked]>
Date: Fri, 15 Jan 2016 08:39:44 +1100

In light of the objections to publishing a document for eCall, does it make sense to reconsider the WG's previous decision to make Carcrash dependent on eCall?

That is, decouple them so that the required specification can move ahead.

Cheers
James

Sent from my iPhone

> On 15 Jan 2016, at 5:24 am, Brian Rosen <[email-masked]> wrote:
>

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 14 Jan 2016 22:47:39 +0000

Adding Georg Mayer to the discussion thread - not sure the "[email-masked]" actually works.

Kind regards

Ivo Sedlacek

-----Original Message-----
From: Alissa Cooper [mailto:[email-masked]] 
Sent: Thursday, January 14, 2016 8:14 AM
To: Ivo Sedlacek
Cc: DRAGE, Keith (Keith); Ben Campbell; Marc Linsner; Liaison Statement Management Tool; [email-masked]; Barry Leiba; Emergency Context Resolution with Internet Technologies Discussion List
Subject: Re: [Ecrit] New Liaison Statement, "Reply LS on eCall support for the EU from IETF Ecrit WG"

Hi Ivo,

Alissa

---

From: Randall Gellens <[email-masked]>
Date: Thu, 14 Jan 2016 16:11:37 -0800

At 8:39 AM +1100 1/15/16, James Winterbottom wrote:

>  In light of the objections to publishing a document for eCall, does 
> it make sense to reconsider the WG's previous decision to make 
> Carcrash dependent on eCall?

I don't see any realistic risk from the IETF proceeding with both 
documents, and hence, no need to decouple nor delay them.  The scope 
of the drafts is quite limited and has been well-known in the eCall, 
NENA, 3GPP, and IETF communities for years, and seems well aligned 
with the anticipated direction of future work.  In the extremely 
unlikely event of an inconsistency, we can do a bis.

>>  But let's ignore this distinction, especially since what we WANT 
>> the telematics guys to do is to redirect the call to 
>> urn:service:sos and request the telematics operator as a 3rd party 
>> using a "Referred-By" header.  In that case, it would be an 
>> emergency call. But we already have "Additional Data" being sent, 
>> and car-crash just extends that.
>>
>>  Brian
>>
>>>  But eCall INVITE has Request-URI set to an emergency URN, right? 
>>> So, it is an *emergency* call and every *emergency* call 
>>> regulation will apply to it, correct?
>>>
>>>  Kind regards
>>>
>>>  Ivo
>>>
>>>  Cc: DRAGE, Keith (Keith); Ben Campbell; Marc Linsner; Emergency 
>>> Context Resolution with Internet Technologies Discussion List
>>>  These calls are NOT treated as emergency calls between the 
>>> vehicle and the telematics center.  The underlying carrier is 
>>> unaware of what the call and/or data represents.
>>>
>>>  Brian
>>>
>>>>  So, basicall, you are saying that radio network of 3GPP 
>>>> operators will be used for transport of the eCall....
>>>>
>>>>  Assuming eCall is treated by regulators as other emergency 
>>>> calls, the regulators will make 3GPP operators responsible for 
>>>> routing eCalls.
>>>>
>>>>  Therefore, 3GPP needs to study how the impact on 3GPP operators 
>>>> (both on radio network and on SIP indrastructure) can be as 
>>>> minimal as possible. Based on the outcome of this study, the 
>>>> IETF draft might need changes....
>>>>
>>>>  Kind regards
>>>>
>>>>  Ivo Sedlacek
>>>>
>>>>  Cc: DRAGE, Keith (Keith); Ben Campbell; Marc Linsner; Emergency 
>>>> Context Resolution with Internet Technologies Discussion List
>>>>  Most of these systems use existing 3G/4G network data channels I 
>>>> believe.  That part is proprietary and we don't care.  The part 
>>>> that we're dependent on is from the telematics company to the 
>>>> PSAP.  These systems have proprietary protocols from car to the 
>>>> telematics company and then standards based protocols from the 
>>>> telematics company to the PSAP.
>   >>>
>>>>  Brian
>>>>
>>>>> with Internet Technologies Discussion List
>>>>>> ("car-crash") dependent on the eCall draft.  If we delay the 
>>>>>> eCall draft, we can't publish the car-crash draft and that is 
>>>>>> a problem, since we need to implement it.
>>>>>>
>>>>>>  Brian
>>>>>>
>>>>>>>  If by stop you mean delay the publication request to IESG, 
>>>>>>> then that should definitely occur, and I believe several 
>>>>>>> posters have stated this.
>>>>>>>
>>>>>>>  There is no point in publishing this as an RFC until the 
>>>>>>> response of a 3GPP network is known, as a 3GPP network is the 
>>>>>>> only delivery mechanism for such a call. As such, I request 
>>>>>>> again that no publication request is submitted for these 
>>>>>>> documents until some work on the 3GPP side has occurred, and 
>>>>>>> people are able to comment on the drafts based on the 3GPP 
>>>>>>> requirements.
>>>>>>>
>>>>>>>  Keith
>>>>>>>
>>>>>>>  Subject: Re: [Ecrit] New Liaison Statement, "Reply LS on 
>>>>>>> eCall support for the EU from IETF Ecrit WG"
>>>>>>>
>>>>>>>  Hi Ivo,
>>>>>>>
>>>>>>> reflect those people's expectations about what may arise out 
>>>>>>> of 3GPP. Of course if the drafts become RFCs and it turns out 
>>>>>>> that 3GPP's requirements don't match up, there's always the 
>>>>>>> option of doing bis drafts.
>>>>>>>
>>>>>>>  I'm just reflecting back what I believe the will of both this 
>>>>>>> WG and 3GPP to be - as I said, the liaison statement doesn't 
>>>>>>> ask ECRIT to stop its work and wait, and it was my impression 
>>>>>>> that WG participants here didn't think that was necessary 
>>>>>>> either. But if the WG consensus would point in the direction 
>>>>>>> of waiting, that would be fine too.
>>>>>>>
>>>>>>>  Alissa
>>>>>>>
>>>>>>>>>  The plan is to continue progressing the drafts and for 
>>>>>>>>> those who are involved in both to keep an eye out for 
>>>>>>>>> potential areas where there might be a lack of 
>>>>>>>>> harmonization.
>>>>>>>>
>>>>>>>>  Subject: Re: [Ecrit] New Liaison Statement, "Reply LS on 
>>>>>>>> eCall support for the EU from IETF Ecrit WG"
>>>>>>>>
>>>>>>>>  We've known for awhile now that the 3GPP work was going to 
>>>>>>>> be somewhat delayed compared to the IETF work. The plan is 
>>>>>>>> to continue progressing the drafts and for those who are 
>>>>>>>> involved in both to keep an eye out for potential areas 
>>>>>>>> where there might be a lack of harmonization. I think this 
>>>>>>>> is implicitly reflected in the liaison statement the WG 
>>>>>>>> received - it doesn't ask the WG to stop what it's doing.
>>>>>>>>  Alissa
>>>>>>>>
>>>>>>>>>  The underlying problem here is that SA2 has not yet done 
>>>>>>>>> enough work (as in none) to see if the IETF drafts meet the 
>>>>>>>>> 3GPP requirements. The SA2 study is critical to this.
>>>>>>>>>
>>>>>>>>>  Cc: Ben Campbell; Marc Linsner; Emergency Context 
>>>>>>>>> Resolution with Internet Technologies Discussion List; 
>>>>>>>>>  Title: Reply LS on eCall support for the EU from IETF Ecrit 
>>>>>>>>> WG Submission Date: 2015-12-02 URL of the IETF Web page: 
>>>>>>>>> <[email-masked]>,Ben Campbell 
>>>>>>>>> <[email-masked]>,Alissa Cooper <[email-masked]>,Roger 
>>>>>>>>> Marshall <[email-masked]>,Emergency Context 
>>>>>>>>> <[email-masked]>, Response Contacts: [email-masked] 
>>>>>>>>> Technical Contacts:
>>>>>>>>>  Purpose: In response
>>>>>>>>>
>>>>>>>>>  Referenced liaison: Liaison Statement on NG eCall support 
>>>>>>>>> for the EU (https://datatracker.ietf.org/liaison/1412/)
>>>>>>>>>
>>>>>>>>>  Body:
>>>>>>>>>  1. Overall Description:
>>>>>>>>> informing 3GPP of IETF work enabling eCall over IETF SIP. 
>>>>>>>>> SA2 has agreed on a work item (enclosed) in SA2#111, see 
>>>>>>>>> WID (S2-153654) "Evolution to and Interworking with eCall 
>>>>>>>>> in IMS Stage2".
>>>>>>>>>

-------------- Randomly selected tag: ---------------
> This is not to say that programming in, say, C++ takes a
> super human effort.  What I mean is that it makes sense to
> develop tools that lessen the effort and increase the chance
> for success.  C was a step in that direction....

First there was ALGOL... this was a big step in the right
direction, then CPL which was supposed to be practical ALGOL,
was a slight step backwards.  BCPL which was Basic CPL was
another step backwards.  Then came B, a big step backwards (it
took the Basic and dropped the CPL), and C was a small step
forwards over this.  I think in all this C had by the time it
came around lost the plot.

The plot that it really found, which was more by accident than
intention was cross platform development, but that would have
been in ALGOL anyway.  C did not prove that OSs could be
written in HLLs: that belonged already to ALGOL on the B5000
(~1964), and this OS survives today as still much better,
fully featured and robust than Unix or any other OS for that
matter.

As C.A.R Hoare said, Algol was a great improvement on most of
its successors.

  --from Usenet post by Ian Joyner,
    <http://www.mri.mq.edu.au/people/ian.html>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 15 Jan 2016 02:29:26 +0000

With emergency call we have a some criteria we try and meet while still using the underlying mechanisms of the basic call. The first of these is that the emergency call does happen, so 3GPP uses a special access mechanism to ensure where appropriate higher priority and robustness for the emergency call on the radio access. Secondly in a 3GPP world things are internationally mobile so there is a need to ensure that a PSAP in the correct country is reached, over and above any national breakdown of PSAP distribution. Thirdly, different countries have different requirements on receiving spurious emergency calls, and some will not route an emergency call that has not been "verified" in some manner.

With ecall, I would see two issues that need extensive review:

i)	there are requirements (from 3GPP) for interworking with the existing CS domain service. These complement the existing emergency call handling in 3GPP were the network and the UA cooperate to select the best of CS and IMS (SIP) to route the emergency call.

ii)	where the "sos" subtypes are not supported, 3GPP defaults to sending it to the PSAP that handles the higher level subtype or "sos" generally. There care needs to be taken that ecall as a subtype as no detrimental impact on such PSAPs that such calls might get routed to, either by preventing the ecall in the first place, or ensuring that it defaults to media the PSAP can handle.

Failure to meet these needs could result in both legal and regulatory constraints.

With car crash, every time we ask the question about what access technology is used, we keep getting a lot of hand waving with statements that it will be proprietary and US only. Apart from the fact that the charter of ECRIT is not meant to deal with national emergency systems, but provide mechanisms in multiple countries, I have to note that cars tend to be international commodities in their use. What happens when the car crash system leaves the country of its regulatory framework. 

Further the call is still a SIP call. So, given that the claim is made that it can operate "off the radar", and given that it is still using an sos URI, what mechanisms exist to prevent it somehow straying outside the proprietary connection mechanism and into some other SIP handling system, such as IMS or the European M493 work. If it can do this, it definitely needs review outside IETF.

All the above reviews should occur as a result of developing the 3GPP feature, and to jump that would be premature.

Regards

Keith 

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: 15 January 2016 00:12
To: Ivo Sedlacek; Alissa Cooper
Cc: Ben Campbell; Marc Linsner; Liaison Statement Management Tool; DRAGE, Keith (Keith); [email-masked]; Barry Leiba; Emergency Context Resolution with Internet Technologies Discussion List
Subject: Re: [Ecrit] New Liaison Statement, "Reply LS on eCall support for the EU from IETF Ecrit WG"

> Carcrash dependent on eCall?

I don't see any realistic risk from the IETF proceeding with both documents, and hence, no need to decouple nor delay them.  The scope of the drafts is quite limited and has been well-known in the eCall, NENA, 3GPP, and IETF communities for years, and seems well aligned with the anticipated direction of future work.  In the extremely unlikely event of an inconsistency, we can do a bis.

>>  But let's ignore this distinction, especially since what we WANT the 
>> telematics guys to do is to redirect the call to urn:service:sos and 
>> request the telematics operator as a 3rd party using a "Referred-By" 
>> header.  In that case, it would be an emergency call. But we already 
>> have "Additional Data" being sent, and car-crash just extends that.
>>
>>  Brian
>>
>>> So, it is an *emergency* call and every *emergency* call regulation 
>>> will apply to it, correct?
>>>
>>>  Kind regards
>>>
>>>  Ivo
>>>
>>>  These calls are NOT treated as emergency calls between the vehicle 
>>> and the telematics center.  The underlying carrier is unaware of 
>>> what the call and/or data represents.
>>>
>>>  Brian
>>>
>>>>> believe.
>>>>  So, basicall, you are saying that radio network of 3GPP operators 
>>>> will be used for transport of the eCall....
>>>>
>>>>  Assuming eCall is treated by regulators as other emergency calls, 
>>>> the regulators will make 3GPP operators responsible for routing 
>>>> eCalls.
>>>>
>>>> (both on radio network and on SIP indrastructure) can be as minimal 
>>>> as possible. Based on the outcome of this study, the IETF draft 
>>>> might need changes....
>>>>
>>>>  Kind regards
>>>>
>>>>  Ivo Sedlacek
>>>>
>>>> that we're dependent on is from the telematics company to the PSAP.  
>>>> These systems have proprietary protocols from car to the telematics 
>>>> company and then standards based protocols from the telematics 
>>>> company to the PSAP.
>   >>>
>>>>  Brian
>>>>
>>>>>> eCall draft, we can't publish the car-crash draft and that is a 
>>>>>> problem, since we need to implement it.
>>>>>>
>>>>>>  Brian
>>>>>>
>>>>>>> WG and 3GPP to be - as I said, the liaison statement doesn't ask 
>>>>>>> ECRIT to stop its work and wait, and it was my impression that 
>>>>>>> WG participants here didn't think that was necessary either. But 
>>>>>>> if the WG consensus would point in the direction of waiting, 
>>>>>>> that would be fine too.
>>>>>>>
>>>>>>>  Alissa
>>>>>>>
>>>>>>>>> who are involved in both to keep an eye out for potential 
>>>>>>>>> areas where there might be a lack of harmonization.
>>>>>>>>
>>>>>>>> in both to keep an eye out for potential areas where there 
>>>>>>>> might be a lack of harmonization. I think this is implicitly 
>>>>>>>> reflected in the liaison statement the WG received - it doesn't 
>>>>>>>> ask the WG to stop what it's doing.
>>>>>>>>  Alissa
>>>>>>>>
>>>>>>>>> SA2 has agreed on a work item (enclosed) in SA2#111, see WID 
>>>>>>>>> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2015-12-
>>>>>>>>> 02-3gpp-tsgsa-sa2-ecrit-reply-ls-on-ecall-support-for-the-eu-f
>>>>>>>>> rom-ietf-ecrit-wg-attachment-1.pdf
>>>>>>>>>
>>>>>>>>> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2015-12-
>>>>>>>>> 02-3gpp-tsgsa-sa2-ecrit-reply-ls-on-ecall-support-for-the-eu-f
>>>>>>>>> rom-ietf-ecrit-wg-attachment-2.pdf
>>>>>>>>>

-------------- Randomly selected tag: ---------------
> This is not to say that programming in, say, C++ takes a super human 
> effort.  What I mean is that it makes sense to develop tools that 
> lessen the effort and increase the chance for success.  C was a step 
> in that direction....

First there was ALGOL... this was a big step in the right direction, then CPL which was supposed to be practical ALGOL, was a slight step backwards.  BCPL which was Basic CPL was another step backwards.  Then came B, a big step backwards (it took the Basic and dropped the CPL), and C was a small step forwards over this.  I think in all this C had by the time it came around lost the plot.

The plot that it really found, which was more by accident than intention was cross platform development, but that would have been in ALGOL anyway.  C did not prove that OSs could be written in HLLs: that belonged already to ALGOL on the B5000 (~1964), and this OS survives today as still much better, fully featured and robust than Unix or any other OS for that matter.

As C.A.R Hoare said, Algol was a great improvement on most of its successors.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 15 Jan 2016 08:48:41 +0100

James, this sounds reasonable to me.

---

From: Randall Gellens <[email-masked]>
Date: Fri, 15 Jan 2016 11:54:46 -0800

At 2:29 AM +0000 1/15/16, Keith (Keith) DRAGE wrote:

>  With emergency call we have a some criteria we try and meet while 
> still using the underlying mechanisms of the basic call. The first 
> of these is that the emergency call does happen, so 3GPP uses a 
> special access mechanism to ensure where appropriate higher 
> priority and robustness for the emergency call on the radio access. 
> Secondly in a 3GPP world things are internationally mobile so there 
> is a need to ensure that a PSAP in the correct country is reached, 
> over and above any national breakdown of PSAP distribution. 
> Thirdly, different countries have different requirements on 
> receiving spurious emergency calls, and some will not route an 
> emergency call that has not been "verified" in some manner.
>
>  i)	there are requirements (from 3GPP) for interworking with the 
> existing CS domain service. These complement the existing emergency 
> call handling in 3GPP were the network and the UA cooperate to 
> select the best of CS and IMS (SIP) to route the emergency call.

Yes, and these are all outside the scope of the IETF drafts.

>
>  ii)	where the "sos" subtypes are not supported, 3GPP defaults to 
> sending it to the PSAP that handles the higher level subtype or 
> "sos" generally. There care needs to be taken that ecall as a 
> subtype as no detrimental impact on such PSAPs that such calls 
> might get routed to, either by preventing the ecall in the first 
> place, or ensuring that it defaults to media the PSAP can handle.

Yes, and NG inside the US treats all subtypes of "sos" as "sos" until 
the call gets to an ESInet.  Inside an ESInet, differentiations can 
be made if desired by the ESInet rules, but these are all outside the 
scope of the IETF drafts.  However, the drafts have taken into 
account that calls carrying crash data (or any type of additional 
data) may be handled by a PSAP that does not support crash data.

>  With car crash, every time we ask the question about what access 
> technology is used, we keep getting a lot of hand waving with 
> statements that it will be proprietary and US only. Apart from the 
> fact that the charter of ECRIT is not meant to deal with national 
> emergency systems, but provide mechanisms in multiple countries, I 
> have to note that cars tend to be international commodities in 
> their use. What happens when the car crash system leaves the 
> country of its regulatory framework.

I'm sorry that you think there has been any hand-waving, Keith.  The 
car-crash draft discusses current deployments within the U.S., and 
migration to NG.  One of these models uses proprietary mechanisms 
between the vehicle and a service center, but standard mechanisms 
from the service center to the PSAP.  Other models use standard 
mechanisms from the vehicle direct to the PSAP.

>
>  Further the call is still a SIP call. So, given that the claim is 
> made that it can operate "off the radar", and given that it is 
> still using an sos URI, what mechanisms exist to prevent it somehow 
> straying outside the proprietary connection mechanism and into some 
> other SIP handling system, such as IMS or the European M493 work. 
> If it can do this, it definitely needs review outside IETF.

Of course the calls can be placed as IMS emergency calls from a 
vehicle.  This is one of the deployment models.  Such calls will 
carry various forms of additional data, including basic additional 
data and crash data.  This isn't new and doesn't raise any new issues 
with 3GPP IMS.

>
>  All the above reviews should occur as a result of developing the 
> 3GPP feature, and to jump that would be premature.
>
>  Regards
>
>  Keith
>
>  Cc: Ben Campbell; Marc Linsner; Liaison Statement Management Tool; 
> DRAGE, Keith (Keith); [email-masked]; Barry Leiba; Emergency 
> documents, and hence, no need to decouple nor delay them.  The 
> scope of the drafts is quite limited and has been well-known in the 
> eCall, NENA, 3GPP, and IETF communities for years, and seems well 
> aligned with the anticipated direction of future work.  In the 
> extremely unlikely event of an inconsistency, we can do a bis.
>
>>
> direction, then CPL which was supposed to be practical ALGOL, was a 
> slight step backwards.  BCPL which was Basic CPL was another step 
> backwards.  Then came B, a big step backwards (it took the Basic 
> and dropped the CPL), and C was a small step forwards over this.  I 
> think in all this C had by the time it came around lost the plot.
>
> intention was cross platform development, but that would have been 
> in ALGOL anyway.  C did not prove that OSs could be written in 
> HLLs: that belonged already to ALGOL on the B5000 (~1964), and this 
> OS survives today as still much better, fully featured and robust 
> than Unix or any other OS for that matter.
>

-------------- Randomly selected tag: ---------------
In America, anyone can become president.  That's one of the
risks you take.                           --Adlai Stevenson