RE: [Sipping-emergency] proposed charter, new wg on emergency calling and routing

["Marc Linsner" <[e-mail]>]

I too agree this work is much needed.

Other comments in-line.....

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Brian Rosen
> Sent: Monday, September 27, 2004 9:59 AM
> To: 'Peterson, Jon'; [e-mail]
> Cc: [e-mail]
> Subject: RE: [Sipping-emergency] proposed charter,new wg on 
> emergency calling and routing
> 
> 
> I am very happy to see some motion on this very pressing 
> problem.  In the absence of IETF work, other national or 
> regional groups are working on solutions that are contrary to 
> the "no national variants" of the Internet. I do think 
> mention should be made of other work, perhaps explicitly 
> soliciting requirements from such entities as NENA and ETSI EMTEL.
> 
> There are several problems that need to be solved that go 
> beyond this particular problem statement.  The most 
> significant is that the location that is supplied needs to be 
> "validated" prior to using it.  This is a primary problem, 
> and it's essential that it be included in the charter. I 
> believe that making scope so narrow that only routing is 
> considered would be a serious mistake.
> 
> Another issue is that while in some jurisdictions, there is a 
> single location to which calls are directed, in some, the 
> nature of the emergency determines the routing.
> 
> Another issue missing from the charter is an explicit 
> inclusion of both civic and geo locations (street address and 
> lat/lon/altitude).
> 
> The charter needs to cover location precision to at least a 
> room.  It's not clear if this is in scope or not.  The 
> mechanism to determine location is not in scope, but 
> representation, and thus validation, should be.
> 
> Specific suggestions on the wording of the charter follow:
> 
> 
> > 
> > Emergency Context Resolution with Internet Technologies (ECRIT)
> if validation of location is considered, this would not be a 
> great name
> > 
> > 
> > Transport Area Director(s):
> > Allison Mankin <[e-mail]>
> > Jon Peterson <[e-mail]>
> > 
> > Transport Area Advisor: TBD
> > 
> > Working Group Chairs:  TBD
> I volunteer

I volunteer also.

> 
> > 
> > In a number of areas the public switched telephone network 
> (PSTN) has 
> > been configured to recognize a short, easily memorized number as
> > a call for emergency services.   These numbers relate to an 
> emergency
> > service context and depend on a broad, regional configuration of 
> > service contact methods and a geographically constrained context of 
> > service delivery.  Successful delivery of an emergency service call 
> > within those systems requires both an association of the physical 
> > location of the originator with an appropriate emergency service 
> > center and call routing to deliver the call to the center.
> This is incorrect.  You don't always have a short number, 
> choice of number is currently explicitly national (with the 
> single exception of the EU 112 number primarily limited to 
> mobile).  There is more to location within emergency calling 
> besides "context" and there are more than location that may 
> determine the appropriate call center.
> 
> Perhaps:
> Calling for help using the publics switched telephone network 
> (PSTN) is a primary function which must be provided for in 
> any Internet based communication system.  Emergency calls for 
> assistance are answered at special call centers.  An 
> emergency call must be directed to the correct call center, 
> which depends on the location of the caller and in some 
> jurisdictions, the nature of the emergency.  The call itself 
> must include the location either directly or indirectly.  
> Prior to use for determining a call center location must be 
> determined to be valid (known to the call center as a 
> location to which help may be dispatched).

I don't believe the IETF should require validation, this is a local
decision.  The IETF can describe/develop the mechanism for validation, but
it is the user(s) to determine the requirement.

> > 
> > Calls placed using Internet technologies do not use the 
> same systems 
> > to achieve those goals, and the common use of overlay networks and 
> > tunnels (either as VPNs or for mobility) makes meeting them more 
> > challenging.
> Okay
> 
> > There  are, however, Internet technologies available to describe 
> > location and to manage call routing.  This working group 
> will specify 
> > how those technologies
> > may be used within this context.  
> This presupposes that the available technologies are 
> appropriate.  This might be true, but it might not.  Perhaps: 
> Describing location and carriage of location within various 
> protocols is defined in other IETF working groups.  This 
> working group will specify how location, in both civic and 
> geospatial forms can be validated and used to route calls.

Agree with Brian, if existing technologies can't fulfill the requirements,
something new will be needed.

> 
> >Explicitly outside the scope of this
> > group
> > is the question of pre-emption or prioritization of 
> emergency services  
> >traffic.  This group is considering emergency services calls which 
> >might be made by  any user of the PSTN or Internet, as opposed to 
> >government or military  services that may impose very different 
> >authentication  and routing  requirements.
> Is this an attempt to avoid the scope of IEPREP?  If so, it's 
> incorrect. IEPREP is concerned with an entirely different 
> kind of call - one made by a responder using the existing 
> facilities using a priority.  Agree that this is out of 
> scope.  There is no call for assistance (9-1-1/1-1-2) that 
> has preemption that I am aware of.  Priority for emergency 
> calls is often imposed by carriers, but rarely required.  If 
> you intended to avoid IEPREP,
> perhaps:
> This group is concerned with calls made by ordinary users to 
> request emergency assistance.  Emergency calls by responders 
> using Internet facilities are the province of the IEPREP 
> working group and out of scope for this working group.  
> 
> > 
> > The group will describe a layered approach to the problem, 
> showing how 
> > the availability of location data and call routing information at 
> > different steps in session setup would enable communication 
> between a 
> > user and a relevant emergency service enter.
> It's not clear that there is any layering.  I think this 
> wording doesn't advance anyone's understanding of what the 
> work is.  Perhaps: This group will describe how location may 
> be validated prior to use, and how validated location may be 
> used to route calls to the correct emergency call center.

Validation is one process that would apply to civil locations only.


> 
> >Though the term "call routing" is used in this document,
> > it
> > should be
> > understood that some of the mechanisms which will be 
> described might 
> >be  used  to
> > enable non-voice communications (e.g. text messaging) where 
> appropriate.
> I'm not sure what is implied here.  There are two kinds of 
> text messaging protocols that might be used: Instant 
> messaging and interactive text streams.  Both have the notion 
> of "session".  Perhaps: While current emergency calls are 
> voice only, the Internet provides a variety of media streams 
> that may be used to summon help.  This work will include 
> voice, video and Instant Messaging as well as interactive text.
> 
> 
> > 
> > Deliverables:
> > 
> > Informational RFC describing the problem
> >     (needs to be simple and early, early, early)
> > 
> > BCP describing strategies for call originators identifying 
> emergency 
> > calls.
> >     (Including provisioning local targets and use of URIs)
> This is somewhat problematic as it overlaps protocol groups. 
> Maybe need to qualify this as with the concurrence of such 
> groups (I'm thinking SIPPING and XMPP).  Wording may need a 
> hint of the "nature of the emergency" problem.
> 
> > 
> > BCP describing strategies for associating call originators with 
> > physical locations.
> >     (Both originator-based and network-based strategies)
> I'm not sure what is meant here.  Right now, I think most 
> endpoints learn location from DHCP and supply it using 
> SIP/XMPP with PIDF-LO.  It's worth saying that somewhere.  Is 
> that what was intended by this?  I hope you did not intend to 
> imply network based insertion of location in call flows; I 
> think we are constrained by geopriv to have endpoints learn 
> location and supply it on emergency calls.
> 
> Need a new requirement
> Standards Track RFC describing how location is validated prior to use.

Again, civil location validation as required by the user(s).

> 
> > 
> > Standards Track RFC describing a query protocol for 
> Emergency Service 
> > Context lookup  by physical location.  Update, insert, and 
> > modification of the data
> > associated
> > with ERC's is out of scope for this work item.
> I don't see how you can ignore how the data is maintained. I 
> suppose it depends on the query mechanism; if you choose the 
> right query mechanism, there may already be mechanisms for 
> maintaining data.  
> 
> >     (IRIS might be a candidate protocol here--it is a query only 
> > protocol for registry data,
> >      which is one way to model the back end store mapping 
> location to 
> > ERC).
> This should be deleted.  You don't know what query mechanism 
> to use.  If, for example, you use the DNS, than this is incorrect.

Agree with Brian, delete this statement as mechanism is
yet-to-be-determined.

> 
> > 
> > BCP describing the call routing strategies for ip911.
> very poor choice of acronym; has U.S. implication.  Use ipSOS
> 
> >     (e.g.:  does an ERC have a sip: URI to talk to, or do 
> we need to 
> > last mile via PSTN?)
> I suspect we DON'T want to work on migration strategies.  
> Just assume the ERC can terminate a SIP call.  It's too late 
> for IETF to wade into that one.
> 
> > 
> > BCP describing how to discover ERC capabilities.
> >     (can a deaf person IM this center or can we route through a 
> > relay?)
> I'm skeptical of this, again crosses protocol groups 
> boundaries.   Problem
> does need to be solved.  Perhaps:
> BCP describing how routing may be affected by capabilities in 
> the ERC or constraints on the caller (e.g. caller with 
> disabilities engaging a relay service).
> > 
> > Threats and security documentation
> >     (mainly pointers, but the pointers need to be gathered).
> > 
> 
> 
> Brian
> 

-Marc Linsner-


_______________________________________________
Sipping-emergency mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sipping-emergency