Emergency Context Resolution with Internet Technologies WG ========================================================== MONDAY, March 23, 2009 1520-1720 Afternoon Session II Room: Continental 5 Chairs: Marc Linsner, Hannes Tschofenig Secretary: Roger Marshall Randall Gellens: Jabber Scribe (cc'd here) Richard Barnes: Scribe (cc'd here) Chairs presentation Phonebcp & Framework presentation (Brian Rosen) Ted Hardie: Want a pointer that directs those Brian: Randall: Applicability statement would clarify Keith: Phonebcp points to the Framework, so problem lies with the Framework, so framework should say "this is one framework", others may exist. Hannes: When you say for VoIP solutions, saying there are other solutions out there - obviously is just fantasy. This is not so much about emergency, but about SUPL or not SUPL. In other instances, such as the location specific stuff, (Geopriv), SUPL, for example, was left out - Richard Barnes: In most all the other examples of protocols and solutions, within each of those, we don't state within the document that there other (competitive) examples of how to do similar things. Randy: The present wording is not usual for the IETF, to have a clarify… through a new document. Ted: In order to move forward, if the chairs would accept another document into this work group would be something to take back to Stephen Edge. (I think) this is probably better written by 3GPP, not here, and I think this subject is different than typical Keith: Within a system, deploy a framework - Jon (Peterson): A confusing discussion, not sure I share Ted's view - all documents suffer from this kind of effect. Wouldn't think it is unreasonable to insert text - if we know it - to include it. Ted: Hannes: I'm going to close the line after Henning. I don't think we're getting anywhere with this discussion. Henning: All documents by the IETF are stating an informed opinion, and reflects the desire of the technical future of emergency calling. Other documents have their own forums to express - if the document is deficient, then that's one thing, but to have a bunch of what amount to lawyer words isn't what we need. Marc: Ted proposed that we can always have another Do we need applicability statements covered by the Framework & Phonebcp that we need to clarify. Keith: Marc: What's you're asking for, is "if you implement this this way, then here's what will happen" Brian: That seems like motherhood… that all parts need to be implemented to have the solution work. Hannes: Randy: would there be any harm to adding text? Marc: If you believe we need to add applicability statements to framework and phonebcp, then Hmmm. (No consensus - per Jon Peterson) End/ /next Lost Synchronization -04 status Henning: Ted: LDAP synchronization experience - eventually found that the big providers didn't want it to happen, since they thought there would be a tendency to have to buy a great big box from "vendor O", Henning: Version -05 will likely include experimental (results?) End/ /next RPH resource priority header James Polk: Janet Gunn: I sent email - wanted you to address section 8 (not 9, which I don't care about) James: I will make that additional change. Janet: Under figure 2-1, modified normative change - e.g., with this wording - would mean that ets would not… So just back out of saying it’s a normative change to RFC4412. James: agree to back out Janet: Janet: one inconsistency - towards the end, compared to section 1… (6th paragraph) examples of not going to a PSAP, whereas in section 5 it is to a PSAP. James: Suggest you & I get together to make changes. Marc: Since we've moved the document to a trusted parties, do we really need to say its within an Esnet - haven't heard anything said about "trusted parties". James: Marc: I thought your trusted parties included non Esnet… James: For example, if in a ATT network… Marc: James: that's as far as I wanted to take it. Back to the slide…. Nothing new in this slide. James: Orange net is the Esnet, in that is the trusted… everything else is out of scope. Marc: You'll get together with Janet and spin a new draft James: Yes, probably this week Marc: so that means people will have to read it. End/ /next Rough Location - Richard Barnes Nothing has changed in these slides since last time. Richard: Two questions… Richard: I thought this had already been adopted as a wg item Hannes: Yes, charter has been updated, we were waiting to get phonebcp & framework shipped off, then publish the updated charter… James: Do you have any new information Richard: The document states, if you are a location provider, and if you can provide a better location, then you must send a location URI (implies a precise location) James: Martin Thomson: Provide some additional information - on timing - some people believe 10-15 seconds is a very good number. Ted: traditionally, you have to limit the type of URI, by specifying it. Richard: I think we cant punt this to James' conveyance document. Brian: I think that can work… End/ /next Sos-parameter draft - presented by Keith Drage Keith: Hannes: I think Gonzolo's review included some confusion around "must" statement… End/ Marc: Propose different order for the last 4 presentations (7,8,9,10) if no one objects. 8,9,10,7. (no objections) /next Policy for defining new service labels (RFC5031bis) Henning Schulzrinne Henning: Hannes: Yes, this went to the list for discussion… and changes this to make it by expert review rather than by RFC. Ted: Henning: Hannes: Please hmm if you are ok with this change? Hmmm was in favor of making this change to be done by expert review No hmmm against. End/ /next Extensions for unauthenticated & unauthorized devices Henning Schulzrinne Henning: Questions, Is there a need for this draft? Is it ready as a problem description? Adopt as a WG item? Marc: my experience is that regulators typically don't read RFCs Someone who does read it might do it, the guy who says "leave me alone" isn't going to do it. Henning: Hoping for, "I want to do the right thing" for those visiting this area…" to build a network that satisfys public interest and in the area of fraud. Marc: What if we name one "data only" and name another one, " Henning: So if we had a scenario where you plug into an ethernet jack (where there is no support), and then a banner pops up (as it were) "no emergency use" Bernard Adoba: There are two regulatory initiative related things just now that relate to this, __________ and 802.21 emergency Hannes: how would that work in this specific context - where devices have no identity. Bernard: Henning: Hannu: The only thing we can guarantee is "non service". No way to guarantee that "it will work if you try it now". Henning: yes, things are this way, "best effort" Hannes: I had already asked the working group if they wanted to work on it - there seemed to be acceptance - big question is, are we heading in the right direction. Please hum now if you think it is going in the right direction… Hmmm if it is (medium) Hmmm if you don't think it's in the right direction (none) End/ /next PSAP callback Henning Schulzrinne Henning: Steve Norreys: Are you implying something that you put into the hands of the user? …marking (advertising that this is the PSAP calling) may be detrimental to what you want to have happen. Henning: No requirement that the PSAP has to use this mechanism. Henning: good statement to add - not meant to be routine proceedure. Henning: draft is in requirements stage - 3 solution approaches. Keith: There was a question at the end - do we make this a wg item? Henning: Hannes: Brian has some solutions in phonebcp document, now the question is - do we need something beyond the phoncebcp doc, and if so, which of those things do we want? Keith: I want to define better what we mean by PSAP callback - my own interest is in the area where the call event is still in progress. Keith: the last bullet introduces the idea that this isn't meant for emergency calls? Henning: Brian: I am a supporter of this work - not sufficient, but is important. One distinction is that this is the union of those - is exactly a PSAP making a call back". Marc: the third one is there to remove the "god status". Hannes: Hmmm - who is in favor of doing this work in this wg? (Medium amplitude - In favor). (faint opposed). Hannes: Next step is choose which solution form. Darryl Malice: Wanted to ask Henning, so to better understand what you're saying… Henning: the service provider could say, "if the union of these conditions are met", then instead of failing the call, Darryl: How do I know that this is a 9-1-1 call? Not yet clear to me what End/ /next Premature disconnect Brian Rosen Status - we had a informal interim meeting to try to get some agreement/consensum - didn't get it - though the arguments got more defined. Randy: I don't think that this was about…(missed) Brian: Some list tracking of what the other group wants to do. Ted: 2 things - one existing user experience, though this is existing for some jurisdictions and for some types of calls. Ted: Is there some better approach to getting this…. Brian: I will agree that the user experience is limited, but is not limited by… Ted: It is limited by some types of UI on those phones. Brian: I personally think that is ________, but I do understand you ponit. Henning: We have this model, like the s/w developers in the 80's, the waterfall model, where the jr. dev hands off to the sr. dev. And there are real costs involved, and it may not be worth doing it. I.e., if this is really painful, then let's not do it… Henning: …there are a set of stepping stones that get closer, not that you do nothing or do everything. I would feel more comfortable if we came up with a document modification that would… since there is not a single disconnect requirement. Henning: if we can address the concern, that we'd like to do this, but if we find out that… Keith: I don't think we've reached the point where I want this document to move forward. All you did was to place a statement in the last revision, that says that the "user"… Brian: I got rid of all language that was device specific. Randy: Note that often in the ietf we have where one group of people want a lot of features, and another group don't want any of features, so have often been able to add "some" of the features - those that everyone can agree on. Then see, if we have to add extra signaling, if we do, then we add it. Spencer: Right now we're wedged - both sides want to do it well - where the perfect is the enemy of the good. Henning: my perception here is that if we find out a few years down the road, at that time, we can then inform by real world experience. Brian: we don't! we're not guessing. You've asked for something that we can't discount - the user experience. Henning: only have the cradle device. Brian: no, we're all talking about the same thing - it alerts Henning: The user experience that you've trying to drive is driven by the user device. Brian: The solutions you have described have done alerts, when the user has done something. Brian: point it - did the device do something that causes the alert, or is it the PSAP that causes the alert Ted: We ask, where do we go from here. E.g., what will make most of us happy, or "Is there a bigger problem?" Ted: Is there a class of problems, where someone is given control? By looking at other use cases… Brian: I'll give it some thought. Brian: Deal with the other statement on incremental - these are devices that you throw away. Henning - you obviously don't have an Iphone... Brian: 2 or 3 decades to upgrade PSAP. Henning: we have not separated out 2 pieces of the problem 1. this is the case of the truly accidental disconnect. 2. non-accidental, but premature disconnect. Henning: problem is that number of cases where each of these occur, may well be different. The solution space for those two may well be different. Unless we separate out this big ball of wax… Brian: As long as we're continuing…it requires that one end (PSAP) is more rational. Hannes: 1. Problem statement, and 2. an editorial problem - need someone to volunteer to edit that is more neutral 3. Some straw-man proposals Brian: weird as may be - may be good to ask the groups for solutions written from both groups. /end /end of ecrit meeting 1720