Emergency Context Resolution with Internet Technologies WG (ECRIT) Agenda for IETF 67 TUESDAY, November 7, 2006 1300-1500 Afternoon Session I Grande Ballroom A Meeting Minute Taker: Spencer Dawkins. 1. Agenda Bashing, Document Status and Milestones ------------------------------------------------- Marc Linsner (15 minutes) Marc starts with his presentation No agenda bashing noted a. draft-ietf-ecrit-requirements-12.txt b. draft-ietf-ecrit-service-urn-05.txt c. draft-ietf-ecrit-security-threats-03.txt Have been forwarded to the IESG for publication (the good news), may hear back from them (the bad news). Proto writeup is all done. We're running close to our milestones (amaze your friends in the IETF). There is now an unofficial ECRIT blog from the supplementary web page, and an implementation tracker page (with mailing list - contact chairs to join). 2. Report about the SDO Emergency Services Coordination Workshop ---------------------------------------------------------------- Hannes Tschofenig (30 minutes) Hannes starts his presentation . Acknowledgements to those who helped and participated... Several links to information are included in the slides from the presentation. More than 30 presentations from various SDOs. * 3GPP - had already had a workshop with 3GPP in July, were already aware of many details, but 3GPP2 also confirmed requirements. * IEEE 802.11 emergency service identification, location, unauthenticated access. * IEEE 802.1AB - link layer discovery protocol and LDP-MED. * Several presentations from ECRIT WG. * PacketCable showed architecture and solutions. * NENA * TIA -TR-45 * OMA * ITU-T - focused on early warning, not working on 911 * ETSI EMTEL doing requirements, * OCG talked about GML * EU Commission (regulatory framework, player responsibilities in our architecture) * COMCARE pointers to OASIS standards for authority-to-authority communication, * ESIF NGES talked about NENA i3 requirements and their plans to build on those requirements * ANSI HSSP offered forum for standards and coordination. They are also working on a white paper. * US department of transportation * Emergency Services in Austria - for current VoIP provider * Emergency Services Prototype from Henning. Major open issues * Architectural * Whether to send location information to the endpoints * Who should develop which protocols * Role of a "global coordinator" Next Steps * Schedule another workshop in six months * Inform other SDOs about this work * Request feedback from other SDOs about LoST, Phone BCP, etc. * Topic-specific liaisons, if necessary (discuss this with IAB) * Perform workshops with SDOs on selected topics - possibly IEEE, OMA - IPR policy incompatibility concerns here Peter: concerns about streaming from this workshop, poor quality Hannes: We are going to work on this aspect for the next meeting. Henning: We should also mention the versioning problem. Some people are supporting existing PSAP architectures, NENA i-2, not i-3 versions. Marc: i-2 is being stretched to cover more environments (mobile, etc, never intended to cover these). Brian: Effort in NENA is to get i-3 deployed as quickly as possible, but funding issues are serious. Most people differentiate between current system and next-gen stuff, redoing entire system. Trying to fund this is challenging. I was quite optimistic after the SDO emergency services meeting. WiMAX folks were worrisome, but they made a connection that didn't exist before the meeting. Need to follow up with IEEE/WiMAX, need better communication. Hannes: Please keep in mind that WiMAX is different to the IEEE. Wimax just uses IEEE 802.16e. Steve Norreys: we have the list of problems that need to be solved, but slides didn't capture synergies between groups. They vary by timescales, but that's the only difference, this is their opportunity to push the world. Bernard Aboba: What liaison does this working group want to carry forward? At your disposal if you have a plan. Brian: I have a specific suggestion: a joint meeting between 3GPP and IETF was productive. I would like to see same thing with IEEE. Bernard: Could start with a conversation. Don't even see IEEE groups talking to each other, so there's still work to do. Jonathan: Device move into another network and it simply doesn't work. Need some common fallback, etc. Bernard: look at IAB liaison documents - WGs can send letters (with WG consensus) - get things down on paper first, where others can look at it Brian: start with framework document and ask for comments, then we can work on details Hannes: I suggest to get the framework document in a good shape first before we send it to other SDOs. 3. A Location-to-Service Translation Protocol (LoST) ---------------------------------------------------- draft-ietf-ecrit-lost-02.txt Andy Newton (15 minutes) Pattern now is three request elements and response elements Find service Include attributes added to show valid/invalid/unchecked. Author team met this week, has additional changes they want to make. Service Boundary reference added for low-bandwidth clients, etc. Brian: question the use of this - if you can't handle a large amount of traffic, you still get it when you dereference? Henning: not convinced it's a huge advantage, but assume service boundaries are political and long-term stable. Retrieve once and check for changes. Andy: don't know if anyone has talked about deltas for the deferenced information. Henning: maybe have a smaller description of a simpler polygon - not sure worthwhile to have this complexity. Brian: complexity tradeoff could also be how often you get complexity Andy: interesting in many ways, take this conversation to the list. Like Henning's use case, hadn't thought of that before Hannes: discussed at last meeting, people complained, Austria and US had large polygons for service boundaries. Henning: don't have to get too uptight about protocol complexity here. Andy: need to talk about lifetime of reference, etc. Unchecked indicator added in this version of the spec. Brian: unchecked is very valuable. On list - is there hierarchy? Location profiles are biggest addition in this version of the document. Geo is where the number of identifiers really goes up. Multiple namespaces, very flexible. Rohan: really like this, mandatory-to-implement is a really good thing. Brian: useful enough to replicate to other location users (location conveyance, etc.)? Andy: good point. May want to talk about this. James: geoshape only defines half a dozen shapes - is that reasonable? Andy: don't think everyone supports all the shapes. No one has defined what 3D looks like. Prism doesn't exist yet ... the return value is the interesting part. No one has defined all the details. Andy: service boundary and location element both support multiple namespaces MUST IMPLEMENT profiles - geodetic-2D, civid Client must support both 2D and civic responses, servers must implement both. Open issues * Error responses changed. * TTL will be absolute. * "include" effects on caching * Ordering of element names * Order preference of location profiles * Algorithm for adding (was lost) * Loosen uip service value syntax * Signing Rohan: should have multiple display names, will post to issue tracker Andy: good suggestion. Want to separate errors from warnings, SIP interaction will be specified in another document. Steve Norreys: still worried about this - person making emergency call needs to do something, but they will be panicing. Machine can do this, but people behave strangely Henning: We want to return something useful if possible, but may be nothing useful to return (invalid country code, etc). Hope is that we don't need to do this at call time. What if there's no emergency equipment there? Errors come in several flavors (don't understand specific request, don't understand location information). If you can return a default value, please do that. Andy: benefits no one to return an answer with an error. Authors think errors/warnngs make more sense, enable resolver data insertion, move to absolute TTL to accommodate D-SIG (just not in this pass). There is a difference between asking about locations and asking what services are supported for the location. Ted: Making location option seemed to be the right thing to so, please check this Brian: big step forward, still have a hole about finding servers in the forest. Henning: charter date for this item, want to get this work done. Addressed all known issues? Second - create new document, not even chartered yet. This is a synchronization problem. Not THAT complicated, needs to be done. Andy document will go to WGLC soon (couple of weeks?) Keith: geopriv issue, still have no way to map errors to the different protocols. Henning: author team talked on this, not on these slides. Will do the same thing as SIP - when we change protocols, we add a flag. Marc: how many people understand this draft? Please comment soon! want WGLC before too much longer. Hannes: We also need to apoint some expert reviewers: Jonathan Rosenberg, Tom Taylor, Shida Schubert, Steve Norreys 4. Location-to-URL Mapping Architecture and Framework ----------------------------------------------------- draft-ietf-ecrit-mapping-arch-00 Henning Schulzrinne (15 minutes) Document hasn't changed much, so these are upcoming changes. Two-minute refresher... Resolvers know forest guides, not trees. Forest guides are neutral arbitrators. Individual "trees" will share information. Caching required for resiliency, at multiple levels. Basic text is stable, need to generalize to multiple services, need to move operational guidance to BCP. WGLC after next revision (01). Hannes is grabbing volunteer reviewers: Cullen Jennings, Rohan Mahy, Murugaraj Shanmugam, Richard Barnes Brian: I don't know whether the architecture is right until I see the protocols Hannes: I got you Brian. With the ECRIT work you wanted to see the architecture document first before you wanted to work on the details. Now it is the other way around. Andy: don't think we need to see this document to do the protocol. Brian: this is so basic... needs to correctly reflect the protocol. Henning: we can panic later if this document is really late. Jonathan: with Brian - this is hard stuff, should take a look later. 5. Framework for Emergency Calling ---------------------------------- draft-ietf-ecrit-framework-00 Brian Rosen (15 minutes) Should not have any normative text in this document (please let Brian know if you see any). Changed terminology. Need to update to match LoST 02. Open issues - marking, insufficient review. Want to make sure the document is right, means what it says. Hannes - finished by December? Solicit feedback from external organizations, need time for this. Expert reviewers? Jonathan? Peter? Steve? yes. Andy: marking is in framework document? Brian: yes, but normative is in phone BCP. Andy: can we come to resolution here? If we have time. Keith: anything special about call-back? Do we mark these as special? Brian: don't think this is completely specified. 6. Best Current Practice for Communications Services in support of Emergency Calling ---------------------------------------------------- draft-ietf-ecrit-phonebcp-00.txt Brian Rosen (15 minutes) Updating to reflect mechanism changes in LoST No open issues, but marking will lead to changes. We currently don't need expert review, but please comment. Keith: document requires you to reveal your identity, unless you are using an anonymizer. Peter: document structure - another BCP on system side and infrastructure? Brian: clients and servers in this document - could rename the document to reflect this, don't think we're breaking document into two parts. Should give guidance to anyone to show what they must do with this stuff. 7. A DHCP based LoST Discovery Procedure ---------------------------------------- draft-polk-ecrit-dhc-lost-discovery-01.txt Henning Schulzrinne (5 minutes) DHC will be one of several such mechanisms (like SIP configuration, Geopriv on list discovery, etc.). Draft is one powerpoint bullet - one domain name, no IP addresses or anything else. You do translation before you send request. Doman name representation has been worked out with DHC chairs. Assume exactly one LoST server, use NAPTR for multiple servers. Need to do joint last call with DHC, no dependencies on anything else. DHC will do review at the end of our process. Who has read the draft? A few. Progress as WG item? Humms - many yes, no "no" humms. 8. IANA Registering a SIP Resource Priority Header Namespace for Local Emergency Communications -------------------------------------------------- draft-polk-ecrit-local-emergency-rph-namespace-00 James Polk (5 minutes) Indications for mesages - had a spare four hours and wrote this draft, just a new resource priority namespace, didn't propose a specific namespace, but there are several alternatives, don't care which. Just floating the idea - resource priority took six years, need to start now. NENA needs this. Requires standards-track RFC. Multiple priorities? in the draft, not a solid proposal. 4412 goal is not to have lots of name spaces, so looking to consolidate. Jonathan: Worried about this for users making calls. We already have marking on the call, can't allow this if call isn't emergency call, so it should already be marked. James: Brian and I agree, this is the alternative marking proposal. Jonathan: Mark me opposed! Henning: I have raised my objection already on the mailing list - conflating user authority and forwarding authority - need one namespace. Be careful - marking emergency calls has a lot of side effects, bundle so you can't get one without the other. SIP has lots of headers already. Don't look at details of this proposal, look at broader marking discussion. Brian Stucker: Callbacks don't suffer from huge authorization problem, don't have other considerations for this. Brian: Useful for call-in/call-out, asking for resource priority, do have some redundancy, but they mean different things and have different effects. Janet: These namespaces are not expected to be used for PSAP-PSAP or PSAP-first responders. Steve Norris: Would all be marked in the same way and treated the same way - we have two kinds of marking (off and on). Ted: Understand issue Jonathan raised and agree. If you aren't also going to service URN as a target, this shouldn't work, but ... there is a tight binding here. Jonathan: when you have two things that have to be the same, then you're introducing error conditions where they aren't the same. Ted: Is inferring this sufficient? Henning: Last thing we want to do is fail the call - at least handle at normal priority, not drop. Henning: Marking needs to survive translations (redirections, etc.). Would be nice to ensure that only emergency calls get this marking, so you can never call your aunt as an emergency call unless she works at a PSAP - these are two core requirements. Request URI, To URI, special header, caller preferences, parameter - these are the possibilities. Brian: Route? Henning: probably not, identifies PSAP but not marking. Choices seem to be request URI and route header. Steve Norreys: Separation of marker from routing. You could do reconciliation. Lots of operator systems in UK, but not emergency calls. Henning: This was first requirement. Jonathan: only thing you use is the marker that says "going to PSAP" - this is the request URI. Henning: People haven't read draft, so maybe we should give people time to digest. Henning: BCP-level thing - is it the obligation to verify route at every proxy? James: Focusing too much on only getting to a PSAP, that's only part of the problem. Going from a PSAP to a valid person? Brian: this would work, because if you hand off, you're still going to onother PSAP. Henning: "I'm an emergency operator, you should check out your account". Authorization is more trait-based. Keep this separate because issues are different. James: Trait-based assertion is harder on intermediate nodes. Jonathan: This is a general SIP problem. Every proxy has to have rules for routing incoming requests. You're in this framework. ???: Problem with 3GPP - request URI has backwards compatibility problems if we're not using telephone number. Dennis Burke? Interest is for routing, not priority? Henning: Solve routing problem first, then make determination about whether request URI is sufficient or now. Brian Stucker: Has nothing to do with authorization, proxy has to do lots of checks anyway before treating the call specially. Don't understand combining who I am calling and how I am handling the call. Don't agree you have to solve the routing problem first. "This is the way I want to be treated", regardless of routing. (Out of time at this point)