Minutes for ECRIT at IETF-92
minutes-92-ecrit-1

IETF92 ECRIT Minutes

Note taker: Roland Jesske (some edits by R. Marshall)

10 min * Agenda Bashing, Draft Status Update (Chairs)

Agenda Bashing:
Short discussion about additional data.

Brian Rosen: What needs to be done for additional data.
Answer: It is done, from perspective of the authors. Thus WLGC is in progress
and will move it forward.

Christer Holmberg: Indicated that also text needs to be added to describe how
the media plane is needed to send data. Randall Gellens: It [currently] says
that sending large amounts of data inband in is not recommended, but is
allowed. Brian: If comments haven't been addressed [prior] then they will be
addressed now.

Document status. see slides

20 min * Internet Protocol-based In-Vehicle Emergency Calls (Randall Gellens)
http://www.ietf.org/id/draft-ietf-ecrit-car-crash-02.txt

Summary:
Discussion went around [and around] whether this draft does or does not address
emergency calls and if a data only option should be considered in addition.

Notes of discussion:
Randall: Draft was revised. This draft is intended to be specific for North
America. Keith Drage: It has fundamental problems. This draft needs to indicate
that this is not be used for an emergency call. A distinction is needed to
indicate what this draft describes. Is this an emergency call or not? It needs
also to say what will happen in the case that a device roams onto another
mobile network.

Randall: This draft does not define call procedures.
This document do not talk about LOST.
Keith: Yes it does.
Randall: This draft makes an informal reference that describes what LoST does -
as compared to what this draft does. VCC and Roaming are out of scope of this
draft.

Keith: To state that this is not an emergency call, then what is needed is to
remove all references refering to emergency. Randall: The Draft does not say to
use mobile network for emergency purposes.

Brian: It could be described how it works in an 3GPP emergency case. But that
is not currently done in the draft.

Randall: The URN is only doing this for the Main URN and not for the children
[sub URNs].

Keith: Assumption is that if a call is routed towards the Circuit Switched
network then it needs to be an voice call.

Brian: would like to cover the case where no voice slot is available that data
only would be possible as an option.

Keith: If you have a 3GPP emergency call a data only call is not possible. Then
the Data only option is not possible.

Conclusion
• Brian is requesting a data only option.
• Draft needs to be described that 3GPP emergency call is out of scope in this
draft. Randy beliefs that this is already the case, and therefore applies.

20 min * A Routing Request Extension for the HELD Protocol (James Winterbottom)
http://www.ietf.org/id/draft-ietf-ecrit-held-routing-02.txt

James presented remotely.

Summary:
Main discussion taking place around the issue of whether the draft can proceed
as it is or it needs to be extended to allow “full LOST support”. During the
meeting only one person was opposing against proceeding the draft as it is.

Notes of discussion:
Brian: Asks for an example containing the complete LOST response.
James: We do not need this.
Brian: This is against the current proposal and has nothing to do with the IETF.
James: If you don’t have a LOST server you cannot do this.
Brian: Wants to avoid having an IETF document that only supports one use case.
James: In addition to the use case described in HELD, you can add each
information part as you would like. Hannes: Should check how the extension
would be possible in future. Implications need to be pointed out. James: Adding
an extension that allows that to be in the bottom would be possible. Brian:
Would like to have it state that everything that LoST allows can be returned.
James: Cannot do it. It is explained in the draft.

Brian: Object again. Do not have an single use case. He can come up with text.
Randall: Want to see the text.

Conclusion: Brian to send text to allow other use cases as well. Discussion
will take place on the list.

20 min * Next-Generation Pan-European eCall (Randall Gellens)
http://www.ietf.org/id/draft-ietf-ecrit-ecall-02.txt

Summary:
Discussion went around how the draft should proceed. Whether there is a need to
wait for 3GPP as the SDO setting the requirements, or if the draft can be used
as is. A Liaison was proposed to 3GPP to show the status of work.

Notes of discussion:
Randall: similar to car crash document but scoped for Europe. Proposal to move
this forward.

Keith: same problems as with car-crash. 3GPP does not currently address the
eCall. Thus this will mandate how 3GPP has to do this.

Christer: The draft should have a solution which 3GPP can use and will use. The
requirements needs to be added based on that for VoIP.

Roland Jesske: Pointing to the fact that eCall for circuit switched is rolled
out now by operators, and therefore starting now with a draft provided by IETF
could confuse industry providing the devices. Also backwards compatibility is a
big issue to be taken into consideration. Cars are not a short term investment,
and will run 10-15 years with the eCall technology now provided.

Randall: This draft was done by including ETSI requirements as a way to work it
in compliance with the solution provided in future by 3GPP.

Keith: What additional requirements will be provided by 3GPP. 3GPP needs to
discuss the requirements. Work is not started now.

Roland: Clarified about the status of the TR (Technical Requirements). That
this is a Technical Report and is only discovering issues how to do a ecall
solution. But it will not be required to do it as described within this TR.

Georg: pointed out the 3GPP aspects.

Randall: This draft is not yet in working group last call, so we have some
time. And we need to prepared for the future so that vendors can provide the
solution in time.

Georg: Pointing out that we do not want two solutions in the end.

Keith: Has problems, in that in future we need interworking.

Randall: Does not mention anything about interworking.
Randall: Pointed out that similarly this was done with an emergency call which
worked very well.

Keith: Said that the emergency call in 3GPP is now done differently than what
is described in the IETF.

Andrew: Pointed out that he expects the eCall in 2-3 Years to be done.

Georg: Propose that SA1 should look at the ETSI TR.

Conclusion: Prepare a Liaison to 3GPP to indicate that work is done in IETF and
3GPP is asked for comments.

20 min * Indoor Location Mechanisms for Emergency Services (Dorothy Stanley)
http://www.ietf.org/id/draft-marshall-ecrit-indoor-location-00.txt

Summary:
Mainly presenting the ideas of indoor emergency service and what can be used to
provide this service. Possible building blocks where shown and who is working
on that.

Notes of discussion:
Proposal to adopt this draft as Work Item.

Keith: Draft needs to have a conclusion of what can be done to have a solution.
Add text describe what is already done and what IETF needs to do further.

Andrew: same comment.

Brian: Supporter of this work.

Keith: Points out that 3GPP is doing work on emergency call over WLAN. It is
proposed to consider also the work done in 3GPP.

Andrew: Points out that the mechanism could use other mechanisms also.

Conclusion: More discussion is needed.

/end.