Framework for Emergency Calling Using Internet Multimedia
draft-ietf-ecrit-framework-13

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.

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)?

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.

-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.