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 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.