Framework for Emergency Calling Using Internet Multimedia
Note: This ballot was opened for revision 10 and is now closed.
(Cullen Jennings) (was Yes) Discuss
Discuss (2010-03-08 for -)
AD needs to check if any new LC comments came. Few small comments as part of my AD review. Typically I would have sent these before IETF Last Call but given the timing of the IESG calls and next IETF meeting, I decided we could sort them out as part of IETF Last Call. They are all small and could likely be fixed with RFC Editor notes after we decide what they need to say. 6.2.1 Para 2. The statement that user provided location information is less accurate seems to be contradicted by the later statement that emergency responders will be dispatch to user self-declared location. I know what you are getting at here but seems like some words could be tightened up. Section 9.1 - para 1. Typo with the xref. Section 10. The text around the contact header and GRU does not seem right. Are contacts optional in an INVITE? a device with a global reachable IP can still use a GRU. When you say that the B2B contact manipulations should result in a contact header that is usable for call back it sounds like you are saying that current B2BUAs will all do this. Is that true or did it mean to say this can be a problem and they need to do this? The text here just seems to a a bit out of sync with the phone-bcp. Just have a look at this section and see if you think any changes are needed. Section 10. Use of PAI. Need to discuss how this works with anonymous call. Places like women's shelters, or many phones in some legal jurisdictions, typically configure all calls to be anonymous in the 3325 sense yet it seems like they still need call back from emergency call to work. I also wonder about how the spec-T would work. If the solutions requires every service provider to have a spec-T with every psap, this does not seem feasible. How does the PAI not get removed when passing it to out of the domain of the service prover and too the psap? Section 14. 2nd para. At the time this was first written, this was true, however, at this point of time the IETF does have consensus about keying for SRTP. It seems that given that security is desirable, we should use the agreed on keying solution.
(Robert Sparks) (was Discuss) Yes
Jari Arkko No Objection
(Stewart Bryant) No Objection
(Wesley Eddy) No Objection
(Adrian Farrel) No Objection
Stephen Farrell (was Discuss) No Objection
-13 fixed my discuss points, thanks. Not sure if Sean's discuss was sorted or not, so the comment below may now be moot...or not;-) I support Sean's discuss wrt IPR and LC processes. I'm also unclear how IPR that affects this informational document would not affect the phonebcp document but who knows with these things.
(Russ Housley) (was Discuss) No Objection
The Gen-ART Review by Francis Dupont on 2010-03-05 included some editorial comments. Please consider them if an update to this document is needed for any reason.
(Pete Resnick) (was Discuss) No Objection
General comment: Some of the language seems more SIP-centric than it needs to be, and most of the document is not SIP-centric. It provides important information to people implementing emergency calling services irrelevant of protocol. I've given a couple of specifics below. "The IETF has historically refused to create national variants..." seems rather judgemental. How about "The IETF has historically not created national variants..." No mention in made in the intro paragraph of section 3 regarding manual config (where neither measurment nor LCP is used). Example in section 3: Why does the phone get its location both at boot time and at emergency call time? The latter would seem to suffice. Belt and suspenders? Isn't location something that gets periodically updated by most devices anyway? Section 3, Alice example: Why is SIP REGISTER even part of this discussion? Seems to be that SIP register could occur before or after contacting a LIS, and is not really part of emergency calling at all. The dial string appears only to be retrieved at boot time. Doesn't it have to be periodically refreshed to make sure that the current local dial string is correct based on current location? Section 3, top of p. 11: "initial LoST query [M3] to learn a URI for use if the LoST query fails during an emergency call". If the LoST query fails during an emergency call, there is no guarantee that the URI that you got at boot time will be valid anyway. Given that, why isn't there a generic hard-coded "pray and hope someone will help" URI that I can use if the LoST query fails? That is, why do I have to do that initial LoST query at all? Section 6.2.1: The use of the mechanism introduces the possibility of users falsely declaring themselves to be somewhere they are not. As an aside, normally, if an emergency caller insists that he is at a location different from what any automatic location determination system reports he is, responders will always be sent to the user's self- declared location. However, this is a matter of local policy and is outside the scope of this document. I don't understand the hedge. It seems perfectly reasonable to say: The use of the mechanism introduces the possibility of users falsely declaring themselves to be somewhere they are not. However, this is generally not a problem in practice. Commonly, if an emergency caller insists that he is at a location different from what any automatic location determination system reports he is, responders will always be sent to the user's self-declared location. It doesn't sound "outside the scope of this document" at all. 6.2.1 makes more sense to me at the end of section 6.2 instead of the beginning. 6.2.4: Location beacons are end-system measured location mechanisms, not network measured. 6.6 paragraph 1 seems much more about *how* one gets location than *when*. What you are saying here is that if you are getting netwok measured location information, you had better be asking the local network and not some VPN. In the case of NATs, again it's not timing, but mechanism that is important: You had better pass your globally visible address corresponding to your local network and not your NAT address when talking to an LCP. 6.6 paragraph 2: Once per day for a mobile device seems like an extremely low rate. Maybe add a sentence like, "For networks with mobile devices, much higher refresh rates could be expected." 6.7: Why not change section title to simply "Conveying location"? SIP is the example in this section, not the point of it (AFAICT). 6.10: "When validation fails, the location given must not be used for an emergency call." What if I have no other location information? Should I not send something? Or is this supposed to be covered in 6.11 (in which case a forward reference would be useful)?
(Dan Romascanu) No Objection
(spt) (was Discuss) No Objection
(Magnus Westerlund) No Objection
Comment (2010-03-11 for -)
Section 1: PSAP is not explained in this section, please write out on first usage Section 1: NENA (National Emergency Number Association): I guess that this is an USA National association, if that is true please make it clear. Section 6.2.2 The threshold for when interior location is needed is approximately 650 square meters. This value is derived from fire brigade recommendations of spacing of alarm pull stations. However, interior space layout, construction materials and other factors should be considered. In this type of reference it would be good to specify which fire brigade that has this recommendations. I would be highly surprised if the California recommendations are exactly the same as the one in Stockholm.