Note: This ballot was opened for revision 10 and is now closed.
Summary: Needs a YES.
Comment (2011-04-24 for -13)
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
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?
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
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)?
Comment (2011-09-08 for -13)
-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.
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.
Comment (2010-03-11 for -)
PSAP is not explained in this section, please write out on first usage
NENA (National Emergency Number Association):
I guess that this is an USA National association, if that is true please make
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
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.
Comment (2010-03-11 for -13)
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.