[Ecrit] draft-ietf-ecrit-framework-09: review

["Thomson, Martin" <Martin.Thomson at andrew.com>]

General comments:  This document is well written and it conveys the architecture clearly and rationally.  It is a little wordy in places, and it could probably be shortened; however, I see no harm in publishing as is.

This was going to be just a few nits, but some of these are a little more serious.  Of course, none are all THAT serious.

~~

Section 3, Page 7: the second step of the procedural overview can be changed to:

   "o The phone gets its location.  This might be via a Location Configuration Protocol (LCP) ... [LLDP].  Alternatively a phone might be able to determine its location autonomously, for example using a Global Position System (GPS)."

 (suggestion: for the benefit of discussion relating to this overview, it might be helpful to number lists of this sort, rather than use bullets)

Page 8 (same list): the fifth step (third on the page) need not reference DHCP.  Suggest change to:

   "o The phone refreshes its location and updates the PSAP's URI ...  "

Page 9, Figure 1: I don't know what inference you expect folks to make from the association of the LIS and SIP registrar, (dotted line) but it's the wrong one.  Such a grouping can only imply physical proximity or operation by the same entity, neither of which is necessarily true.  I also cannot see why the LoST server isn't similarly grouped.  I'd suggest removal of any grouping.  This extends to the list on Page 10 that groups these.

Section 6, Page 13: the concept of validity with location is not well enough understood to throw out a phrase like "unique, valid location" without explanation.  Readers might look for other hidden meaning in the words chosen here.  Can you clarify that the goal in this instance is to have location information that can be successfully used to route and dispatch.  I'm also not certain that unique is the term you are looking for: unambiguous might be better.  Suggest you either define what you mean, reference 6.10, or both:

   "It is frequently the case that a caller reporting an emergency is unable to provide a valid location (see Section 6.10) that can be used for routing and dispatch."

Section 6, Page 13: While the fact that there are: "overload arrangements between PSAPs to handle each others' calls", is perhaps interesting, this is actually irrelevant in this context and could be removed.

Page 14: s/\. if/\.  If/

Page 14: Avoid making statements that could be proven ridiculous in hindsight such as:  "The actual requirement is more stringent than available technology can deliver"  Also, the sentence on "demising" following this might be true in some cases, but the statement is only loosely linked to the qualification about local regulation.  I think that you can make this message a lot clearer without falling into the twin traps of dating the document or referencing unrealistic regulation from a specific jurisdiction.  The lead-in statement might be sufficient.  It might also be prudent to point out that there are what might be desired (3cm) and what might be settled for (100m).  Certainly, mention that emergency call systems are highly demanding of accuracy:

  "Emergency call systems demand a very high level of accuracy from location.  Regulation on location accuracy can be exceedingly stringent, requiring the best available location technology.  Sometimes, a small error can make a significant difference in the time taken to respond to an emergency.  For example, in an apartment complex, an error of as small as 3cm can mean the difference between one apartment and another.  Highly accurate location information can make a significant improvement in the ability of emergency services to respond to an emergency."

Section 6.1, Page 16: A cell tower identifier is NOT location information.  It's location-related measurement data.  In general, these things don't move, but that's beginning to be a dangerous assumption.  Search for "portable cell tower", or even look to femtocells (although there are efforts to make these effectively non-portable, some of it amazingly ingenious).

Section 6.2: It would be sensible to indicate along with "the order of the locations should be the sender's best attempt to guide the recipient of which one(s) to use" that the _first_ location should be the "best".  Reference Section 6.9.

Section 6.2.1: Another statement of what is jurisdictional policy: 

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

This is not really something that the IETF is qualified to state.  All that needs to be said is that "the policy on whether user-entered location is accepted is one set by jurisdictions" and maybe "some jurisdictions will always respect a user's self-declared location, sometimes above that which is reported by automated systems".

Section 6.2.2: Another statement being made without sufficient authority:

   "The threshold for when interior location is needed is approximately
   650 square meters."

Section 6.2.3: minor correction: A-GPS isn't necessarily provided by the access network, although this is implied by the statement here.  It's also possibly worth noting that with assistance, GPS might be able to meet the timing requirements for routing.

Section 6.2.3: Suggest that you use the more generic Global Navigation Satellite System (GNSS) rather than GPS.

Section 6.2.3: Suggest that you mention the possibility of other autonomous positioning systems.  There are certainly other possibilities, such as the short range beacon arrangement mentioned in Section 6.2.4.

Section 6.4: s/available to entity in the call path/available to entities in the call path/

Section 6.6: Continuing the theme from above regarding cell identifiers, the following statement is true of choices made historically in 3gpp, but even there this is no longer true with JSTD-036B:

   "In mobile handsets, routing is often accomplished with the cell
   site and sector of the tower serving the call,"

Better to simply state that routing is accomplished based on location information that is derived from cell tower and sector.  The key thing here is timeliness; all this seems to do is imply that special exceptions exist.  Even if such provisions do exist, they are likely to be inconsistently supported.

Section 6.6: where does the 3 seconds come from?  Seems a little arbitrary to me.  In Wikipedia parlance: [citation needed].

Section 6.8: the PSAP _should_ use "emergencyDispatch".  After all, if the operator knows that this sometimes takes 30 seconds and they aren't willing to wait that long, they should be able to wind the time back to 10 seconds or whatever is most appropriate.

Section 6.9: s/"derived"/"Derived"/ and reference the IANA registry rather than 4119, which makes no mention of this particular tag.

Section 6.11: Can I suggest that this section also state that the default location should have appropriate uncertainty.  Uncertainty might be all the marking necessary in some cases, but if this is not the case, you have provided no means to mark locations as a fallback.  We can debate the merits of a marking some other time, but the text here implies that there is a marking, where I am not aware of one.

Section 7: Can I suggest that you separate LIS and LoST discovery a little more.  Note that LIS discovery is necessary, but LoST discovery isn't, since the system of forest guides should be able to ensure that a request to any LoST server results in a successful result.  Therefore, static configuration of a LoST server is quite reasonable, whereas we advise against static configuration for a LIS.

Section 7: "The endpoint can also do a DNS SRV query to find a LoST server." To which domain?  Also note that LoST discovery in 5222 and 5223 doesn't use SRV records at all.

Section 9.1: the first sentence here doesn't parse particularly well, even when I allow for  the missing '<'.

Section 14: The ordering goes: text, voice, text, video.  Suggest that you move the statement on real time text after g.711.

Section 15: "<>" sounds like a mighty interesting document.

~~

--Martin








------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]