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

IETF88 ECRIT
This file contains MINUTES followed by the meeting notes at end.
09:00-11:30, Monday, November 4, 2013 Vancouver
Room: Plaza A

=========================================================================
10 min * Agenda Bashing, Draft Status Update
Presenters: Marc Linser, Roger Marshall (Chairs)
Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-ecrit-6.pptx

Note taker: Jean Mahoney
Jabber Scribe: Bernard Aboba
Jabber log: http://www.ietf.org/jabber/logs/ecrit/2013-11-04.html

Blue sheets handed out.
Note Well presented.

Agenda bashing - Marc Linsner

Although Randall missed the -00 deadline for draft-gellens-ecrit-ecall-00.txt
and draft-gellens-ecrit-car-crash-00.txt.  There was no objections to his
presenting both drafts.

Two items added to the end of the agenda:
  Brian Rosen - draft-rosen-ecrit-lost-planned-changes
  Ram Dantu - Next Gen 911 demonstrations of smart phone apps

WG Documents - Roger Marshall

draft-ietf-ecrit-country-emg-urn-00 (close to IESG Submitted)
        Christer will submit new version with IANA changes

draft-ietf-ecrit-trustworthy-location-07 (WGLC Completed)
        WGLC complete - To submit today – needs shepherd doc.

Milestones

Charter submitted, no comments received since last revision. The 7-day review
period ends today.

ACTION: Richard Barnes to check if the charter has to be presented
        in an IESG Telechat to make the changes official.

=========================================================================
20 min * Additional Data related to an Emergency Call
http://www.ietf.org/id/draft-ietf-ecrit-additional-data-14.txt
Presenter: Randall Gellens
This draft was updated today to -15
Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-ecrit-0.pdf

Randall Gellens presented v4 of the slides (not yet available at URL above)
The original presenter, Hannes Tschofenig, was unable to attend.

Randall noted that some of the changes listed in the presentation would be
available in version -16. He requested more reviews and thanked reviewers for
their feedback on previous versions.

=========================================================================
15 min * Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using
the Session Initiation Protocol
http://www.ietf.org/id/draft-ietf-ecrit-data-only-ea-06.txt Presenter: Brian
Rosen Presentation:
http://www.ietf.org/proceedings/88/slides/slides-88-ecrit-1.pptx

Brian presented.

There was a discussion between Brian Rosen and Christer Holmberg on also
including a session-based mechanism using INVITE since MESSAGE does not have a
Contact header field and this has caused problems in 3GPP.

ACTION: Brian Rosen to address callbacks in the draft.

ACTION: Brian Rosen to add how to handle large amounts of data
       using HTTP in the draft.

ACTION: Christer Holmberg to send text on how to treat sessions versus
        non-sessions (INVITE with SDP/no SDP versus MESSAGE) before the
        end of November.

ACTION: Brian Rosen to look at Christer's text and the wg to decide whether to
incorporate into the draft, or into a separate (new) draft.

=========================================================================
15 min * Updating Additional Data related to an Emergency Call using
Subscribe/Notify
http://www.ietf.org/id/draft-rosen-ecrit-addldata-subnot-00.txt Presenter:
Brian Rosen Presentation: slides-88-ecrit-2.pptx

Brian presented.

Brian pushed back on the INFO mechanism since the the PSAP can't control the
rate of updates, and device manufacturers like the SUB/NOT mechanism. Christer
pointed out that there is not a mechanism to authorize a subscription from the
PSAP. Within a session, using INFO, the routing and authorization is taken care
of.

Although neither Bernard Aboba nor Andrew Allen cared for INFO in general, they
agreed that authorization is an issue. Bernard stated that SUBSCRIBEs from
unknown providers won't be accepted.

Randall summarized that for SUB/NOT, anyone can subscribe to the device and the
device doesn't know if the subscriber is authorized. If a session has been
initiated by device, then INFO can be used, which also takes care of the
authorization.

Brian pointed out that the device publishes to a server and lets the server
deal with it, which provides a workaround to the authorization problem and
allows for multiple subscribers.

Randall pointed out that publishing to the server provides a workaround for the
rate of updates also and allows the PSAP to forward. With INFO, the PSAP would
have to mediate. The amount of mediation that a PSAP should do is being debated
in NENA.

ACTION: Christer provide text on using INFO.

ACTION: Once Christer's text is submitted, determine if there needs
        to be a separate draft.

=========================================================================
10 min * A LoST extension to support return of complete and similar location
info http://www.ietf.org/id/draft-marshall-ecrit-similar-location-02.txt
Presenter: Brian Rosen Presentation:
http://www.ietf.org/proceedings/88/slides/slides-88-ecrit-3.pptx

Brian presented.

Marc had questions about versioning - was this feature expected? If the new 
information wasn't understood, how would it be handled.

No one volunteered to review.

=========================================================================
20 min * Internet Protocol-based In-Vehicle Emergency Calls
draft-gellens-ecrit-car-crash-00.txt
Presenter: Randall Gellens
Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-ecrit-4.pdf

Randall presented.

There were questions about getting traction from vendors. It was pointed out
that vendors have been active in this work.

=========================================================================
20 min * Next-Generation Pan-European eCall
draft-gellens-ecrit-ecall-00.txt
Presenter: Randall Gellens
Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-ecrit-5.pdf

Randall presented.

Marc asked for interest. There was interest in the room. Marc called for
volunteers to review the document this month. Christer volunteered some folks
at his company. Martin Dolly volunteered folks at his company.

ACTION: Christer Holmberg and Martin Dolly (or delegates) to review
        the draft this month.

=========================================================================
Planned Changes for LoST - draft-rosen-ecrit-lost-planned-changes
Presenter: Brian Rosen
Presentation: TBD

Brian presented.

Richard Barnes, from the floor, suggested using a TTL mechanism.

ACTION: Brian Rosen to add TTL to the draft.

ACTION: Brian Rosen to explore providing guidance on what
        revalidation periods should be.

=============================================
Demonstrations of smart phone applications for emergency calls and safety
Presenter: Ram Dantu, University of North Texas, Network Security Lab.
Presentation: TBD

Ram Dantu presented three video clips on using smart phone applications (which
use a combination of INFO and local applications) for emergency and safety
calls. Brian Rosen pointed out that the PSAPs have to agree on how this sort of
data should be used before they will use it.

ACTION: Ram Dantu to provide links to the video clips to the chairs.

Raw NOTES as Follows

IETF 88 ECRIT
09:00-11:30, Monday, November 4, 2013 Vancouver
Room: Plaza A

=========================================================================
10 min * Agenda Bashing, Draft Status Update
Presenters: Marc Linser, Roger Marshall (Chairs)
Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-ecrit-6.pptx

Blue sheets handed out.

Note taker: Jean Mahoney
Jabber Scribe: Bernard Aboba
Jabber log: http://www.ietf.org/jabber/logs/ecrit/2013-11-04.html

Janet Gunn (jabber room) - having issues with the media stream

Note Well presented.

Agenda bashing - Marc Linser

Marc - Randy's pan-european draft is not official because it missed the -00
deadline, but if there is no objection, he can present.

Room - No objections.

Brian Rosen - I would like to have time at the end to present
draft-rosen-ecrit-lost-planned-changes.

Ram Dantu - I would like to present a demo on how protocols can adapt to next
gen 911.

Marc - We will put this at back of the meeting. Any objections?

Room - No objections

WG Documents (active) - Roger

draft-ietf-ecrit-additional-data-14
        updated to 15 today. Will be talking about it.
        LC comments changes
draft-ietf-ecrit-country-emg-urn-00 (close to IESG Submitted)
        Christer will submit new version with IANA changes
draft-ietf-ecrit-data-only-ea-06
draft-ietf-ecrit-service-urn-policy-02
draft-ietf-ecrit-trustworthy-location-07 (WGLC Completed)
        WGLC complete - To submit today

Milestones
There were action item from last meeting to update the milestones and charters.
Changes complete and posted to charter page.
Charter submitted, no comments received since last revision. The 7-day review
period ends today. Richard Barnes - may have to be on the next IESG telechat to
be approved. Have to check. ACTION.

=========================================================================
20 min * Additional Data related to an Emergency Call
http://www.ietf.org/id/draft-ietf-ecrit-additional-data-14.txt
Presenter: Randy Gellens presenting; Hannes couldn't join.
Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-ecrit-0.pdf

Slides have been updated. v4 rather than 3

Randy - We wish to thank the reviewers. Further reviews are welcome on version
16.

slide - Pending changes to -15

Some of the listed changes are in -15, the rest will be finished in -16.

Randy - Please review the draft - 15 is out now, 16 out soon. Further review is
useful.

=========================================================================
15 min * Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using
the Session Initiation Protocol
http://www.ietf.org/id/draft-ietf-ecrit-data-only-ea-06.txt Presenter: Brian
Rosen Presentation:
http://www.ietf.org/proceedings/88/slides/slides-88-ecrit-1.pptx

Brian Rosen - WGLC is scheduled for this month. Does anyone have problems?
Looking for support. Any discussion?

Christer Holmberg - Which draft is this?

Brian - you had an issue on the SUB/NOT package draft. I don't think you
objected to this draft.

Christer - I've been arguing for a session-based mechanism.

Brian - That's coming up next with the SUB/NOT presentation, you wanted an INFO
package.

Christer - Is this related?

Brian - No. How you get an eCall without media (no SDP). It uses MESSAGE
instead of INVITE.

Christer - You could have a session without media.

Brian - The only reason for a session is to update the data. Heart rate
monitor, for example, has no media. If you use media, use INVITE. If no media,
use MESSAGE. if you update the data, that's a different draft.

Christer - You can't use INFO without media. Do you see a callback scenario?

Brian - There could be, but you would be calling back a device.

Christer - I would have to check the draft, but there's no Contact header in
MESSAGE.  We've had problems in 3GPP with this.

Brian - Nothing prevents the use of INVITE.

Christer - But it's not described anywhere.

Brian - Write a draft.

Christer - We never an agreement on how you treat sessions versus non-sessions.

Brian - Send text. I don't agree with your INVITE idea.

Christer - Will it go in this draft or be a separate one? Is there's an issue
with callbacks? That needs to be described.

Brian - Send text.

Christer - Does the community have an issue with a separate draft? I think it's
useful.

Andrew Allen - If you are just using MESSAGE, how much data are you moving? You
could use MSRP for big messages and files. This is suitable only for small
amounts of data.

Brian - That applies to INVITE also. If small amount, send in the body,
otherwise send a URL and transfer using HTTP.

Bernard - I think it should be in this draft.

Marc - how many have read?

Room - 3 hands

Brian - there's more that have read it, but they aren't here.

Brian - If Christer sends text, I'll add a section that you can create a
session with no SDP and keep the session up.

Christer - I can do that after the 3GPP meeting - before the end of the month.

Randall - What is the text you want here?

Christer - Without going into design, I want to identify session based,
non-session based. MESSAGE, INVITE with SDP/no SDP.

Randall - And PSAPs have to accept both?

Christer - yes.

=========================================================================
15 min * Updating Additional Data related to an Emergency Call using
Subscribe/Notify
http://www.ietf.org/id/draft-rosen-ecrit-addldata-subnot-00.txt Presenter:
Brian Rosen Presentation: slides-88-ecrit-2.pptx

Brian - Update to be out before the end of meeting.

Brian - I think INFO is a bad idea - the PSAP can't control the rate. It needs
a filter.

Christer - When a PSAP sends a SUBSCRIBE, it can specify the rate control. PSAP
can specify it in the response. The user can always choose not to care. You can
indicate the rate.

Brian - I looked at the RFC, I don't see it. I don't see an equivalent rate
control filter.

Christer - the INFO mechanism doesn't have built in rate control, but for a
specific INFO package, you can.

Brian - SUB/NOT has the right syntax and the appropriate way to do this. I
don't think INFO does. I don't think holding a session up is the way to do
this. We use SUB/NOT in NENA for a lot of other things. I don't know why INFO
is better.

Christer - It's from a 3GPP perspective - you have to authorize a subscription
from the PSAP - there's not a mechanism for that. It's not a SIP thing, it's
3GPP architecture.

Brian - I don't know how to go forward.

Christer - This is how to do it if you don't have session. I'm not saying to
throw this away. But if you do have a session, why can't you use INFO? It's
what INFO is for - the routing and authorization is taken care of.

Brian - I think it's the wrong way to do it. Creating an INFO package is ...

Christer - It's the same data as for the SUB/NOT but put in a INFO.

Brian - I understand.

James Polk - I don't see sending it in the INFO. It doesn't buy you anything.
However I'm willing to have you convince me.

Bernard Aboba - Authorization is an issue. I'm not a lover of INFO packages
either, but it solves the authorization problem.

Brian - We think that the devices have these characteristics  - they're devices.

Bernard - SUBSCRIBEs from unknown providers won't be accepted. These standards
will be thrown away and ignored.

Brian - The device manufacturers like this. The devices send a URI. The device
is in control.

Andrew Allen - I'm not taking a position now. It's not correct to think that
machines won't be using IMS. Need to look at solving the authorization problem.
I don't like INFO. I don't like sessions without media.

Marc - 50/50% split in the room. We have to figure this out.

Brian - I've presented this multiple times, there have been objections, but
there has been no text.

Christer - The first time I raised this issue was in Berlin. I should have
brought text sooner, and I'll do that.

Marc, joking - Roger will print out the 6 page form where you sign and commit
to text.

Christer - If we don't have session-based calls, INFO won't work. Need to
provide some text for INFO.

Brian - This is a short doc, by copy pasting, you'll triple the doc. The size
doesn't bother me. I don't think it's the right mechanism.

Christer - I'll provide text.

ACTION: Christer Holmberg to provide text on using INFO.

Randall - I'm trying to capture the essence of the discussion. For SUB/NOT,
anyone can subscribe to the device and the device doesn't know if the
subscriber is authorized. If it's in a session that has been initiated by
device, you can use INFO and that takes care of the authorization.

Brian - The device doesn't want to run a server, it publishes to a server and
lets the server deal with it. This seemed to get around the authorization
problem.

Randall - To clarify that mechanism - the device would publish whenever it has
updates, but the PSAP and the server control the rates.

Brian - And you could have multiple subscribers. Is that a sufficiently good
answer - to have the device publish to an external server?

Randall - In the case of dissemination of data - the 2 mechanisms to use - with
SUB/NOT, the PSAP could forward SUB/NOT. With INFO, the PSAP would have to
mediate. There have been debates in NENA on how much mediation the PSAP wants
to do.

Brian - the PSAP has to mediate because it knows the responder. Once it selects
the responder, it doesn't have to be in the path.

Christer - We can allow this mechanism. I'm not proposing to throw this away.

Brian - I understand. I think we're done.

Marc - So there are 2 mechanisms, one has been written up, one has not. ACTION:
Christer provide text.

Brian - Then we can look at text and see if it needs to be one or two docs.

Roger - There was an older action on chairs to determine a - there's no single
solution, they are both valid mechanisms. Question will be based on new text.

James Polk - If Christer writes separate draft […]

Brian - Let's not worry about number of docs yet.

Richard Barnes - [concerns about number of drafts… muttered]

=========================================================================
10 min * A LoST extension to support return of complete and similar location
info http://www.ietf.org/id/draft-marshall-ecrit-similar-location-02.txt
Presenter: Brian Rosen Presentation:
http://www.ietf.org/proceedings/88/slides/slides-88-ecrit-3.pptx

Brian - NENA guys want this. Would like to get this moving. Comments or
questions?

Marc - has anyone read this?

Room - No hands.

Marc - Can someone review this?

Room - no response.

Marc - How would this affect LoST from a versioning standpoint? Is there
someone expecting this feature, but the server doesn't have it?

Brian - you think you have a valid location, but you don't

Mark - If you get this back from the LOST server, and you don't understand it,
do you ignore it?

Brian - yes

Brian - if you think about getting a precise location, you can get a pretty
good guess. Washington, D.C. example with NW and SE sections of streets.

=========================================================================
20 min * Internet Protocol-based In-Vehicle Emergency Calls
draft-gellens-ecrit-car-crash-00.txt
Presenter: Randall Gellens
Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-ecrit-4.pdf

John Darrell -We're working with … (ITS ?) - Manufacturers are rolling out
systems. Will you get traction from them and the PSAPs?

Randall - There's a history of existing deployments and this draft describes
current deployments. … ITS is a longer timeframe.

Brian - Next gen 911 would include this as the basis of the work. The Onstar
and Agere (? BMW, Toyota, 3 or 4 others) guys are very active in this work. The
Ford Sync (?) guys haven't been.

Marc - Who has read this draft?

Room - Brian raised hand

Marc, aside to Randall - ….

=========================================================================
20 min * Next-Generation Pan-European eCall
draft-gellens-ecrit-ecall-00.txt
Presenter: Randall Gellens
Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-ecrit-5.pdf

Marc - how many have read the draft?

Room - 1 person

Marc - Before we bring it in as a WG item, we need to look at it. Any
volunteers?

Christer - There are some people in my company, they can look at it.

???, Deutsche Telecom - we're looking at eCall. Make sure it's backwards
compatible.

Andrew Allen - We're working in eCall and are interested.

Marc - Am I hearing interest?

Andrew - there has been some.

Marc - Review sometime in November?

Randy - ETSI would like to be able to reference this draft.

Martin Dolly raised his hand - I or someone from ATT can review.

ACTION: Martin Dolly to review

=========================================================================
Discussion

Marc - we do have extra time for the extra agenda items.

=========================================================================
Planned Changes for LoST - draft-rosen-ecrit-lost-planned-changes
Presenter: Brian Rosen
Presentation: TBD

Brian - An example: the annexation of outlying land and properties into a city.
Addresses change, PSAP changes (city versus county). This invalidates some LIS
records. Not a way for the LoST server to tell the LIS. If we revalidate every
30 days, then the load on the server goes up.

Proposal - An extension to LoST - new element to <findService> request:
- URI to be saved with location
- AsOf date to perform validation against
 - Also includes object pushed to the LIS @ URI that contains AsOf invalidation
 date.

Comments?

Room - None.

Marc - how much location validation is actually happening?

Brian - there are LIS’s that do validation - there are a couple of companies.

Richard Barnes, from the floor - Isn't this a TTL issue?

Brian - You could put a TTL on validation, which would have the same effect -
still load on server with annexation, though.

Barnes - you could

Brian - If I know about annexations within the time period. If the annexation
happens in 60 days, revalidate in 30 days, then fine tune when to look it up,
10 days, - it still creates extra load.

Barnes - it increases load by 10x, compared to what?

Brian - just LIS updates. New addresses.

Barnes - If you validate locations, you would periodically revalidate. The
question is, how long is that period? Maybe 30 days is too high. There's still
a TTL thing with a well-known framework.

Brian - at the cost of increasing load on the server.

Barnes - regardless, there is load on the server from validation.

Brian - you want to revalidate, but what is the period? There is no mechanism
now. TTL is not a terrible idea. It's an independently good idea.  I can add
that to the draft. Good to know what the LoST server thinks the revalidate
period should be. Annexations are not small.

Barnes - there's no consensus or standard on updates.

Brian - if you are growing city, the updates are much faster. Compared to a
rust-belt city.

Barnes - but there’s no guidance. This is important. Do we want more than just
guidance?

Brian - ACTION - I can explore that on the list. Don't want revalidations to
happen right on the change.

=============================================
Demonstrations of smart phone applications for emergency calls and safety
Presenter: Ram Dantu, University of North Texas, Network Security Lab.
Presentation: TBD

Ram - Working on NG 911 services with Henning and Walt Magnuson(?) at Texas
A&M. 4 projects for the National science foundation. I hadn't been following
this work.

Video demo of the use of smart phones in emergency calls.

Text to Speech - allows operator to communicate more clearly.

Operator control of the smart phone camera - zoom, flash etc.

Vital sign monitoring - breathing - place phone on chest.

CPR application - monitors compression - can tell person to compress faster,
deeper.

Ram - remote media control - operator can control sensors. If the caller is
cognitively impaired, the operator can do some of it.

Andrew - is there a link to the demo available?

Ram - yes.

Roger - ACTION send the chairs the link. Make it part of the minutes.

Ram - on the MIT project - working on road safety project. Can get info from
phone about safety info in the car. Giving alerts to driver. Road situation -
bumpy roads etc.

[Folks are having difficulty hearing presentation]

Video presentation - Fox News clip on how to give CPR.

Ram - I've been talking to folks in NENA to reach out to 911 operators for
feedback/requirements

Andrew Allan - Does this use existing motion sensors? How many smart phone
types does it work with?

Ram - It works with existing sensors on the smart phone, 4-5 vendors. For the
CPR application, we've been using folks who had not been trained in CPR.

Marc - what protocols does it use?

Ram - SIP INFO messages.

[laughter]

Allan, joking - if in doubt, use INFO.

Allan - For the CPR application, is the data being passed in INFO or is the app
doing the calculations?

Ram - the application.

Allan - so INFO isn't quite for real time data.

Ram - right.

[laptop issues]

Brian - the problem with this is when you go back to the PSAPS. If it's not
done exactly the same way, they can't use it. This is a known problem. There's
no general agreement. You have to solve the problem of how the PSAPs are going
to do it. How do you deal with sensor data? The EMT, police, operator wants to
see something different. Vendors don't want to solve that problem. Fundamental
problem - How to deal with the plethora of sensor data. How to deal with the
people side - How to train a call taker with deal with it. There are 20k call
takers, they have to be trained.

Randall - standards can help with that.

Brian - you are right.

Ram - that's the reason I'm standing here. People have to agree what PSAP
should expect.

Car safety video - focus on individual cars, and then keep track of other cars.

Ram - just used a mobile phone. Potential applications that can be used.

Marc - comments?

Christer, joking - you shouldn't eat a hamburger while driving a car.

Marc - that's the end of the meeting.