IETF70 - Vancouver B.C. ECRIT - Emergency Context Resolution with Internet Technologies WG TUESDAY, December 4, 2007 1520-1720 Afternoon Session II Salon 3 RAI Track ----------------------------------------- Consolidated ECRIT meeting notes denoted in-line, section-by-section, by individual note-taker as follows: [nt1]= James Winterbottom [nt2]= Peter Blatherwick [nt3]= Alex Mayrhofer Note: Only minor spelling changes made to the original submitted notes - where obvious. Consolidated by: Roger Marshall * Status Update and Agenda Bashing Chairs [nt3]SDO meeting - planning shirts & they're going to be shipped to participants :-) [nt3]There were 5 regulators there + EC officials, learned from each other. [nt3]There is a new regulatory framework to be released this month - received a sneak preview. [nt3]Brian: draft of this is out since about 2 weeks - brian will send link out. [nt3]There were PSAP operators out there as well, they are open to experiment [nt3]Audio recordings will be put up on Hannes' website as well. 1. Status update on LoST - Ted Hardie: * IESG Comments regarding LoST, LoST mapping architecture and LoST discovery Chairs http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-06.txt http://www.ietf.org/internet-drafts/draft-ietf-ecrit-mapping-arch-03.txt http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discovery-02.txt [nt1]Current status just finished with last call IESG and comments back from AD, IANA and others No protocol changes expect, language changes only Section 7 change to provide a forward reference to 8.3.1 or replicate the text, author team will make a decision. [nt1]Channel security will be mandatory to implement but use will be recommended. [nt1]Will add an informative pointer to the service URN draft. [nt2] Update on status of LoST (not on other related drafts) see slides [nt2] Questions / discussion points: [nt2] Do we need forward reference consensus: make a decision [nt2] Channel security, does it need to change from RECOMMENDED. Should implementation be MUST or SHOULD? Brian: Needs to be MUST, leave it to BCPs recommend when to use it. Consensus agreed. [nt2] Should pointer to URN draft be added? No objection, taken as consensus [nt2] Draft revision, hopefully before end of Dec (Ted) [nt3]just finished last call, will be "revised ID needed". significant feedback. [nt3]no significant protocol changes expected. [nt3]expected updates slide. [nt3]issue: redirect on HTTP layer vs. LoST response redirect - that's a different things, need clarifying language on that. [nt3]there was confusion about serviceboundaryreference in 5.6 as well. [nt3]quick questions to the room: [nt3]- Section 7: need forward ref to 8.3.1? authors shall make a decision. [nt3]- channel security: AD says it needs to be MUST. comments? [nt3]Jon: mandatory to _implement_, not to _use_. Sure that sec review might insist on [nt3]Brian: mandatory to _implement_ is fine. [nt3]Take this as an direction. [nt3]- "identity of the service" - shall we put in a reference to the URN draft (which has passed IESG already)? no objection - will add a pointer [nt3]some more editorial cleanup was performed. [nt3]Clarification: URN will be an _informal_ reference [nt3]revised draft to be out before end of December seems possible. [nt3]Jon: we're not discussing the other two drafts? [nt3]Henning: no, only some editorial things received. 2. Open issues with Framework & Phone BCP - Brian Rosen * Open issues with Framework and Phone BCP Brian Rosen http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-03.txt http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-04.txt [nt1]Includes all comments received [nt1]More comments since release. [nt1]This document is stable enough to go last call once location hiding and unauthenticated access is addressed. [nt1]Hannes thought that at the last meeting that these two issues would be left out of this document. Brian says that FCC and Alain said that if there is no location hiding and no unauthenticated access that the solution will not fly. [nt1]Henning indicated that he disagrees with this conclusion. The issues will be discussed later in the meeting. [nt2] Framework has incorporated all comments received so far [nt2] Pending decisions on location hiding and unauthenticated access, document believed to be ready to go WGLC. [nt2] Hannes: Previous meeting decided to leave these topics Brian, LOTS of push-back. Discussion to defer to later in meeting. [nt3]04 incorporates all comments received, some minor comments received after release [nt3]two big issues: unauth access, and location hiding. Brian thinks there is no solution without those two things, except that ready for WGLC [nt3]Hannes: think we left those two things as extensions? [nt3]Brian: heard from FCC and EC that without location hiding it won't be deployed. [nt3]Marc: clear that WGLC means everybody has read it and agrees? [nt3]Lots of people have read the last version (Comments to phonebcp) ======== [nt1]Ready for last call also. Please send comments. [nt1]Same issues as Framework. [nt2] Same status as Framework [nt2] Polled for how many have read LOTS [nt_3]fewer people have read phonebcp in the latest revision [nt_3]incorporates all the comments, again except location hiding and unauth. access pretty much ready for WGLC. we will have another revision, though. 3. (Deferred to end of meeting.) [See below.] * Location Hiding Solution Space Yet to be decided http://tools.ietf.org/html/draft-schulzrinne-ecrit-location-hiding-req-00 http://tools.ietf.org/html/draft-barnes-ecrit-auth 4. (Deferred to end of meeting.) [See below.] * Unauthenticated Emergency Services Yet to be decided http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-access-01 5. LoST Server Synchronizationo - Henning Schulzrinne * Forest Guide Exchange Protocol Henning Schulzrinne http://tools.ietf.org/html/draft-schulzrinne-ecrit-lost-sync-00 Open Issues: - WG document? - Error conditions? - Update element? [nt1]James made comments [nt1]Do we want to make it a WG item? [nt2] Overview of the I-D see slides [nt2] Discussion points: [nt2] Winterbottom: Issue with mapping elements in XML Henning: they are intended to be the same, to be updated [nt2] Winterbottom: Outside of emerg services, need ability to define Civic boundaries, and desirable for the transferred data to be identical to that used in actual LoST servers, and data format to be same for all variants of LoST server ? unclear on exactly what the requirement is; discussion to be taken off-line; text to be added that the intent is to transfer in native format. [nt2] Rosen: NENA will do this quite differently. [nt2] Hardy: Need for conversions to/from a canonical format. At least provides interop of the data itself. [nt2] Roger Marshall: Clarification, NENA is using GML. [nt2] Brian: NENA need is to push FAST a rectangle when boundary changes LoST service takes care of updating Civic. [nt2] Issues: [nt2] Error conditions [nt2] Updates relative to new LoST [nt2] WG item? Strong hummm in favour. Consensus, draft update will be new ecrit-xxx-00. [nt3]has been around for a while, think we should discuss whether this is the right direction. [nt3]synchronization of forest guides, authoritative servers, resolvers. [nt3]couple of different "peering" relations. [nt3]AS push "up" summaries [nt3]manually configuaration (changes not very often) [nt3]example slide of "western canada". [nt3]James Winterbottom: would like to use that as well for provisioning the LoST servers. would like to have the same data format for such interactions and the provisioning. [nt3]henning: pretty lightweight, introducing mime-types might not be useful.. LoST servers shouldn't need local knowledge about address formats etc. [nt3]brian: we probably can't use this in places where it would be interesting - data would be pushed out from central database. [nt3]ted: would be a useful thing to have, gives interopability, even if not used for the presented use case. [nt3]roger marshall: nena is working on making all towards GML. [nt3]brian: use case - change border in case of emergency, needs to be quick. we send out one polygon, and this changes the LoST behaviour. [nt3]henning: LoST server is not a geocoding server most of the time, design assumptions... [nt3]pull synchronization: pull current list of mappings. or get updated mappings (new street names). [nt3]hannes: ask the group whether this is to become a WG item. Hum indicates this is WG item. [nt3]Chairs accept that synchronizing LoST servers is WG item - start with henning's draft. 6. Holes in Polygon Service Boundaries - James Winterbottom * Specifying Holes in LoST Service Boundaries James Winterbottom http://tools.ietf.org/html/draft-winterbottom-ecrit-specifying-holes-00.txt [nt1]Still to decide what to do with this document. [nt2] Overview of the I-D ? see slides [nt2] Discussion points: [nt2] Rosen: This (holes) actually happens more than might think in US (e.g. cities within counties) [nt2] Blatherwick: Question, are there cases where we need 3-D. Rosen: Some are possible, e.g. local responders inside a high rise. Cases seem to be encoded in Civic primarily. Alex Mioferd (sp?): There ARE existing case to map exceptions for tunnels standing on same x-y on mountain would get a different PSAP than same x-y in the tunnel through the mountain. [nt2] Issues: [nt2] Should -lost-sych be doc to record the transfer of boundary files? Henning agreed, OK. [nt3]holes are typically an exception. brian: happens more often than you think (county vs. city PSAP). [nt3]boundaries are specified as GML. how to get the hole information across? [nt3]"touching" holes are one hole. [nt3]"inlets" are not holes. [nt3]if hole spans whole polygon, then define two polygons. [nt3]pretty simple, reviewed by a couple of people [nt3]Brian: is this normatively defining how to describe a hole in polygons? 7. Resource Priority Header for ES - James Polk * RPH Header for Emergency Services James Polk http://tools.ietf.org/wg/ecrit/draft-polk-ecrit-local-emergency-rph-namespace-02.txt [nt1]Hannes at the mike. Having 2 ways to do the same thing is not good. [nt1]Henning agrees with this because proxies in most cases will not provide any preferential treatment to priority calls. Specifying an emergency call as a resource priroity is unclean. [nt1]Brian, thinks the draft is useful within the public safety community network. Have multiple RHPs will be used lots and can separate call priority. [nt1]Brian also believes that it is useful outside of this contained network. Proxy servers in the network already understand RPH [nt1]Jon Peterson, sympathetic towards Henning on this discussion. Jon is reluctant to conflate emergency call marking and RPH. [nt1]Richard B says don't call it sos, [nt1]Ted provides an alternative, perhaps ESRP. [nt1]Various discussion about where RPH should be applied and how it relates to emergency calls. [nt1]Henning is concerned about transport across the ES network carrying RPH related traffic that is not actually an emergency call. [nt1]Henning is concerned that we need to have a large number of rules surrounding usage of the RPH, and that just relying on the value of the RPH is not good as it can make a hole susceptable to DoS attacks. [nt1]James asked the question if he kept it only to the ES network would it be okay. Henning suggested that this might be okay. [nt1]Ted Hardie says namespaces are cheap. Have two, one from the proxy to the ESRP, and a different one from the ESRP to ES network. [nt1]Discussion to move the document to SIP. [nt2] Overview of I-D, see slides. [nt2] Discussion points: [nt2] Hannes: Issue with multiple ways to mark emergency call. Henning: leads to a larger discussion; multiple ways to mark leads to more permutations. [nt2] Rosen: Very useful within network supporting multiple RPH values. Implementation exist already that will pay attention to RPH markings, as a way to control resources. [nt2] Jon Peterson: Much of initial discussion came down to domains of applicability. Polk: I-D says can outside of ES domain. [nt2] Richard Barnes: Needs to be clear this is a means of differentiating between types of emergency-related calls. [nt2] Ted Hardy: Suggest change name space to ESRP , make it clear that that's the domain of applicability. [nt2] Drage: This usage of RPH seems appropriate to meaning of these headers. Does NOT relate to routing or anything else. [nt2] Henning: Heartburn is on the left (non-ESRP domain). There are multiple cases on that side citizen to auth, and auth to auth. Coders might implement, and then we have a dangerous DoS hole. No problem for defining this inside ESRP domain only. [nt2] Janet: Left is controlled environment, same as GETS, and that's a good thing. [nt2] Ted: Agreeing, left side is a good place. Middle (eg. in IMS part) may warrant a different namespace name spaces are cheap. Needs serious warnings about abuse potentials. [nt2] Rosen: Policing this is trivial. [nt2] Polk Proposed: Limit scope to left only, change namespace to ESRP. WG direction, no, respin new draft first, and then we'll ask. [nt2] Jon / AD Process: This may be better as SIP work item [nt3]provide an priority indication. NENA wants this [nt3]changes to 02: added where this could be used, nothing else. [nt3]Hannes: With this, we get a second one of marking an emergency call. not good. [nt3]Henning: having two ways to do the same thing is not good, esp. in combinations... [nt3]Brian: we mark things in different ways because of different layers. think there is value there, especially inside the network that handles emergency calls. [nt3]richard barnes: needs to say clearly that its different "classes" of emergency calls, not marks any call as emergency calls. [nt3]Ted hardie: redifine namespace to "SRP" and then define classes there, so that it's "private". [nt3]Keith: support this draft, this is _only_ marking. [nt3]Henning: different if that is used in a closed, authenticated network. different use cases: Fire officer talk to PSAP vs. citizen talks to PSAP. first think might not be an emergency call. means we have to specify rules to when this is being used. could be a nice DoS tool. [nt3]Janet: context is the same - it's the phone system [nt3]if context limited to "right side" and namespace changes to "ESRP", can this be WG item? [nt3]Marc: Let us see the draft first. 4. Revisited - Hannes Tschofenig * Unauthenticated Emergency Services Yet to be decided http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-access-01 [nt1]Hannes is requesting feed back on the terminology from the list. [nt1]Unauthorized with access provider [nt1]Unauthorized with service provider [nt1]SIP proxy has to be associated with the access network or very close to the access network. [nt1]Brian thinks that this is conflating 2 issues. Some networks require this, Vonage UK customer roaming to the US and getting on the IETF network Vonage has to support calls in Canada If it is a UK customer roamed to Canada it must support it. It isn't a case that the connection must be between the access the VSP, but it could be. [nt1]Some debate. Suggestion that the end-point can simply send the call to the ESRP. [nt2] Quick update on I-D, see slides. Terminology a major challenge, due to number of different scenarios. [nt2] Architecture consequence, proxy routing the emergency call needs to be closely associated with access network. [nt2] Rosen: This is not true in all cases not domain of IETF to solve this. [nt2] Henning: Comes down to sharing of auth databases. [nt2] Discussion: [nt2] Rosen: There are real use cases within some jurisdictions where it WILL be required. We must do this. [nt2] Linsner (individual): Who is requiring this today ? nobody. [nt2] Winterbottom: If we can assume the proxy is always (relatively) local, then perhaps we have a much simpler model. [nt2] Issue: Should this be included in Phone BCP / Framework [nt2] Henning: Declare out of scope until someone comes back with general need. Solve individual cases as they come. [nt2] Rosen: At minimum, need to say what we do and don't do. [nt2] Issue not resolved. [nt3]changes: discussed with wimax forum (are currently working on that) it's quite complicated, can't translate the cellular case to IP (because of more entities) eg. no credentials for access provider, if you lost credentials to voip network, etc.. [nt3]unauthorized calls itself are very disputed in the PSAP (switzerland case - extremely high number of bogus calls) [nt3]Brian: some say we've saved lives, we'll keep it (norway). [nt3]Problem: SIP proxy needs to be _very_ closely related to the access networks. [nt3]brian: need to differentiate having the link between access and service or not. [nt3]hannes: eg. here on the IETF, if voip creentials are gone i don't have a voip provider - i'd need to route the call to some proxy i have just discovered.. [nt3]brian: you need to do emergency registration. [nt3]hannes: main point: we're very early, and this work shouldn't go into the framework document. [nt3]is there a proxy or not? only a psap proxy? [nt3]hannes: don't to anything in the framework? [nt3]brian: we have to mention it at least! 3. Revisited - Henning Schulzrinne * Location Hiding Solution Space Yet to be decided http://tools.ietf.org/html/draft-schulzrinne-ecrit-location-hiding-req-00 http://tools.ietf.org/html/draft-barnes-ecrit-auth [nt1]This is not just a technical issue, it is a charging issue. [nt1]Brian has said that our protocols will not be deployed if we cannot support location hiding. [nt2] Not just a technical issue; has ethical implications. See slides. [nt2] Discussion: [nt2] Rosen: If we do not do this, it will NOT be deployed. Regulators, carriers say they absolutely need this. [nt2] Linsner; Why doe this document need to be written here (in IETF). [nt2] Hardie: Can we discuss the tradeoff, which is between deployment ease and ability to correct uncommon mistakes. [nt2] Alex Mayrhofer (sp?): This is complex. May get to legal obligations with customer. [nt2] Winterbottom: Autoconfig mechanisms are highly likely to be correct and accurate, much more so than manual. Human user likely to have little clue how to interpret any info provided. [nt2] Proposals to move forward: [nt2] 1. Limit solution to civic only. [nt2] Rosen: Needs to be taken back to those that say they need it [nt2] 2. Provide an applicability statement black box warning on implications. [nt2] Rosen: No problem with a technical warning. Text posted on list, which could be modified. Does not create new protocol mechanisms. [nt2] No conclusion. [nt3]not purely technical issue. inferior to not hiding, favours access ISPs [nt3]brian: if we don't do this, it won't be deployed. [nt3]marc: then, why has it to be done here? [nt3]henning: we want to have autoconfiguration, and it's bad to not let the user see the location before it's too late