Emergency Context Resolution with Internet Technologies WG TUESDAY, July 11, 2006 1740-1840 Afternoon Session III & IV ===================================================== Chairs: Hannes Tschofenig Marc Linsner Minute Taker: Roger Marshall Jabber scribe Ted Hardie & Andy Newton: http://www3.ietf.org/meetings/ietf-logs/ecrit/2006-07-11.html Slides are available at: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66 * Status Update (10 min) --------------------- Presented by: Chairs Slides can be found here: http://www3.ietf.org/proceedings/06jul/slides/ecrit-3.ppt WG Documents - Status slide WGLC passed and doc ready for IESG Non-WG Items * ECRIT Framework * Mapping Architecture * Phonebcp Rechartering proposal accepted (see docs in bold on bottom of slide) Last Sunday, held an unofficial meeting with 3GPP CT1 and ECRIT groups. Slides are available www.ietf-ecrit.org/3gpp-ietf-2006/ -- SDO Coordination Meeting for ES (1/2) Org lists Henning wanted to host meeting around Sept/Oct 2006 Invitations not yet sent (2/2):: Slide 2 - why is this a good idea? Lots of work going on, (slide) /end of agenda Hannes mentions about several ongoing implementation activities. He will create a webpage to capture information about these projects and learned lessons. James Polk - comment re: service URN wrt to receiving or 'finding' a LoST URI Looked in the service URN draft, did find some but contend that it's incomplete. You have an answer, but don't see how it works. I think it is incomplete. Henning - Late comments for a draft that already passed WGLC James - wants the DNS pieces removed from the draft. URI of the lost DNS-SRV discovery mechanism is partially in the document, but doesn't think it's complete. Andy: Where does the input into the LoST server come from? Henning: 2 pieces for input, 1. Have a domain - refer (likely) to the phonebcp, 2. use a NAPTR record to return a SIP URI. Hannes: Full agenda for meeting - not hearing how this can be quickly resolved. Moving on… * LoST: A Location-to-Service Translation Protocol (30 min) --------------------------------------------------------- Presented by: Henning Schulzrinne http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-00.txt Slides can be found here: http://www3.ietf.org/proceedings/06jul/slides/ecrit-2.ppt Hopes to incorporate Jonathan's comments into draft 01 draft Example queries Still some gaps List of Open issues 3 colors Red - question/issue Green - simple Orange - medium Lavender - complex When does it make sense to have both civic and geo in a query Brought out 2 separate cases: 1. ) same location, but different expression 2. ) geo complemented by civic (hybrid) e.g. floor included Henning sensed more applicability of the second case. Case where you have a geo, plus someone magically gives you 'Room 315' Keith: Is this an ECRIT problem or really a GeoPriv problem? Andy: Perfectly logical for ECRIT to nail down specific Emerg. Svc. action, whereas GeoPriv may be more applicable to non-emergency specifics. Henning: Let's split this up between the two cases Brian: Ask for a hum on no. 1 Marc: RFC 3825 supports a composite location of both types Humm: Who wants to prevent composite location? Y | N [close] Hannes: Consensus couldn't be reached. Let us take it to the list Martin: Comment, your example assumes that you are getting to only one LosT Server, which may not have all the services offered by other LosT servers. You must find the right lost server. Henning: not presented here Henning: Point taken. Issue #4 service urn in Response message What is no specific mapping result? 1, 2, 3, or 4? Henning: I'm agnostic about this. Andy: No strong opinion, but no. 2 ??? Steve Norreys: only when it gets back to the individual user - ???: You certainly don't want to go back to the user Keith: ES only or general service URN? Keith: You may want to just send a reject back to the user. Henning: Option 3 is always available, but for no. 2 you need an additional xml tag. Jonathan: I think in ES, you just use what is there If for pop-up a level (no 2. w/caveat - not nearest guess, but it goes to the next higher level which matches) Keith: Need to put a sensible discussion of these into the document. Henning: Happy to do that Ted: What you've asked for is a child, and you've asked for all children. We plan to put in a bcp? Henning: Unless someone is really unhappy, he'll move with no.2??? Issue #5 PSAP Boundary Hint Lost client indication of PSAP boundary Jonathan: Is there a way to specify not to return a hint? Must do that, since the case of wireless (complex) Andy: suggests at least an option of doing this. Issue #6: Authority Attribute in Lost Response Econ-IRIS Andy: Happy to replace authority with 'via' (though more complex) Issue #7 Adding Additional Info to LoST Response Henning: suggests - don't specify anything, but add flexibility to add some URL later. Issue #8 Should dialstrings be expressed as just numbers, or some dial string format such as KPML? Henning: not convinced that we want patterns for this kind of thing, since it may have more risk for misuse, especially in non-Es contexts (pizza example) Henning: prefers simple numbers. Jonathan: thought you wanted a little more than numbers, given the non-ES available use cases. As a general protocol, might want to make this more general. Brian: prefers dial-string format as with draft-rosen-iptel-dialstring-04 but can get rid of the second bullet Rohan: wouldn't advocate KPML, since that's not what made to do, and when discussions held around this way back when, it was very contentious. Keith: Be careful wrt to pauses wait, flach, etc. Brian: Brought up what if…? Hannes: We need to take this to the list. Henning: Simple wins by default. Andy: we can discuss on the list. Issue #9: LoST response Add preference info Henning: omit this. (no objection) Issue #10: Henning: suggests making it strictly optional (no objection) Issue #11: Referral Protocol mech Andy: Once having done a full scale NAPTR, and you get back a URL - do you follow the URL, or do another NAPTR lookup. Henning: s/b logged as an open issue: Henning: explanation of use case. Keith: are some of these which are requirements - being caught logged, yes. A req doc. exists Ted: strongly prefer a URI to be used. Issue #13: skipped Error Codes: skipped Other open issues: see slide Andy: 1st bullet - are these things that can't put into PIDF-LO? I thought we agreed that we would just use PIDF-LO. Henning: that was before we had a customer requirement. Andy: who puts this info into a lost query Keith: the E-CSCF makes the Lost query Jonathan: A security question - last meeting stated that I liked the idea of having mutual TLS based authentication. I will take it to the list * Framework for Emergency Calling in Internet Multimedia (20 min) ------------------------------------------------------ Presented by: Brian Rosen http://www.ietf.org/internet-drafts/draft-rosen-ecrit-framework-00.txt Slides can be found here: http://www3.ietf.org/proceedings/06jul/slides/ecrit-1.ppt Framework: recently onto the list - please comment on it Purpose is to show how the big pieces work together. won't be normative. Shouldn't be duplicative, but should be standalone. To understand exactly what to do, you'll have to go to other docs as well. Slide - location issues Emphasis in this doc as to 'why' we do what we do Slide - call back and other info There are some new things. E.g. Must include contact And AoR - you need both of them in there. Won't have RFC 2119 language Jonathan: Why not GRUU in the contact? Brian: depends on the context/environment that the phone is being used in. Jonathan: thinks it should say it's a GRUU ???: if Jonathan's system has a gruu, then you should put in a gruu Bullet - next URI pointer for additional info, e.g. medical data Bullet - next Another URI for add call info - relating to e.g., the carrier Keith: no mention of privacy Brian: earlier bullet - opaque URI, opt-in Brian: Some entity will hold the data, will give the carrier the uri. Only something like a PSAP will be able to dereference it. Keith: keep in mind that PSAPs may be authorized to read it, but as they send it downstream, other may not Jonathan: why not a domain with the AoR? Brian: mainly looking for 24x7 NOC contact info Keith: may not be usable (allowable) in Japan e.g. Next slide: Testing See slide Brian: will describe in more detail in doc Ted: is there a reason that it must be a URN? Brian: want to be as close to reality as possible Next slide:: Things to do Wants input - things to do and things not to do? Is it now time to ask whether to make this a working group draft? Hannes: referred to last meeting - where there was overwhelming support Brian: just want to know what the next version name should be. Keith: Wants to know what the scope is Brian: Wants this document to point to the framework (lost) document Hannes: Who is in support of this document? Group: Strong support. No objections. * Best Current Practice for Communications Services in support of Emergency Calling (10 min) --------------------------------------------------------------- Presented by: Brian Rosen http://www.ietf.org/internet-drafts/draft-rosen-sos-phonebcp-01.txt Slides can be found here: http://www3.ietf.org/proceedings/06jul/slides/ecrit-0.ppt List of items to fix gathered from the list. A couple of issue not yet resolved. 1. Not have a list of named mechanisms? (from Patti McCalmont) Brian: Wants to have a list and wants to say that end devices must implement all and the access network devices must implement at least one of those protocols. Marc: How do you keep the list up to date? Ted: Thinks that not having a list is not good. But there is some discussion around which elements have to implement which pieces. Peter B.: Uncomfortable with a phonebcp doc specifying network device requirements. Brian: has questions about whether LLDP, for example should be included. Marc: Docsis device won't ever implement LLDP Henning: Keith: Whatever we say here in phonebcp other SDO's are going to have to review Brian: yes. Ted: If you say, for example, that A-GPS is required on the phone, my company will sell a lot of devices because of that - wants to make sure therefore that we need to be very careful about what we do - so that it is clear that I'm (Ted) am not pushing this for this reason. Next slide: LLDP-MED Brian: Pro- easier than DHCP… Peter: How easy is this to deploy? Peter: Listening to the conversation, its becoming clear that we need some kind of applicability statement. Brian: It is in the text. Still a rev to the document and a rev to every phone. Henning: Caution to say that it 'technically works' - may be impractical to deploy. Not sure we're looking at a dozen years… most Ethernet devices already do LLDP-MED. Brian: Contends that it is trivial to have the IT guy maintain this.? Andy: Talking about wifi only? Andy: Don't worry about wired phones, only about WiFi Brian: Can't do that, already getting issues with phones plugged into hotels… are hotels enterprise or residential? Looks like enterprise. Andy: crappy enterprise. [laughter] Marc: The question is - whether to include LLDP-MED? Peter: proposing to re-arrange the document instead of having a specific list. Hannes: Pretty controversial - let's rev this doc, then have a hum on the list Lots of readers of the document Should the next rev become a working group item? HUmm: Y | N (Yes) * A Dynamic Host Configuration Protocol Option for Requesting and Receiving a Uniform Resource Identifier for a Location-to-Service Translation (LoST) Server (10 min) --------------------------------------------------------------- Presented by: James Polk http://www.ietf.org/internet-drafts/draft-polk-dhc-ecrit-lost-server-uri-00.txt * Learning the Initial Location-to-Service Translation (LoST) Uniform Resource Identifier (URI) During Session Initiation Protocol (SIP) Registration (10 min) ----------------------------------------------------------- Presented by: James Polk http://www.ietf.org/internet-drafts/draft-polk-ecrit-lost-server-uri-00.txt * A Dynamic Host Configuration Protocol Option for the Locally Significant Emergency Calling Dialstring (10 min) ---------------------------------------------------- Presented by: James Polk http://www.ietf.org/internet-drafts/draft-polk-ecrit-dhc-emergency-dialstring-option-00.txt * Using the Session Initiation Protocol REGISTER Method To Obtain an Emergency Dialstring (10 min) ----------------------------------------------------- Presented by: James Polk http://www.ietf.org/internet-drafts/draft-polk-ecrit-emergency-dialstring-00.txt Slides can be found here: http://www3.ietf.org/proceedings/06jul/slides/ecrit-4.ppt 6 internet drafts Two groups talking about 6 topics (see slides) 1. URIs? Or 2. Dial Strings DHCP documents are for all providers small homes - to - large enterprises Client can ask for a new feature, or the server can just supply them Network attachment time (pictures) slide 1 Alice slide 2 Example given: Vonage working under Fcc mandate Next slides showing dhcp call flows. Draft-polk-dhc-lost… (call flow should say Lost Server on right) Next doc bullets (emer dial string) should say 'dial string' instead of URI ???: what is the motivation for putting the country code? James: -> Brian Brian: disputed territory problem (e.g. Palestine or Israel) ???: Why important to give back a dial string, for example specific enterprise dial plan. Jonathan: clarified - do you mean '9-911' dial plan? Andy: why are we doing this here, if we are already doing this in LoST? Marc: what if your UA doesn't have a lost client? Henning: Unless you mandate support for all these mechanisms in all devices, you've got an 'all-in-all' situation. We've got a problem. 2nd point - we're only talking about a small http query. Andy: Martin pointed this out that in order to get a dial string already. James: Not exactly true, some contexts there can only be one dial string. Brian: Problem is that every phone has to implement two protocols, making it onerous to do so in some cases. Brian: if you had a case like we have here in the meeting hall, dhcp might be able to provide 9-911 whereas Lost only returns Henning: it must know its location at the country level Jonathan: If here is the image - if you have an imaginary line with a wireless phone (and you move it over the line) does the 'dial string' change? Brian: Yes, it does. Ted: Concerned in reading these docs a few points: e.g. that the PSAP URI doesn't fit into the slot dhcp provides. Ted: want to make sure that we're careful to make sure what we say will be sufficient (i.e. field fitting) will actually work appropriately. Henning: If using dhcp, the problem is James: new slide: SIP Registration Hannu: revisiting issue of dial string working if crossing over the border, note that ‘9-1-1' would still work. Andy: SBC exist, that's why this isn't a good idea Henning: Sip working group some large number of years ago - some strange sense of deja-vu - this seems like a SIP thing so am concerned wondering whether this is a SIP thing.