RE: [Sipping-emergency] New revision of proposed ECRIT charter

Looks pretty good.  You might expand "NENA" to include other international
agencies.  ETSI EMTEL might be an example.

I take it that the language "Either within that document or as a
> separate
> document, a description of how error conditions are returned to the
> session
> originator
was intended to cover the "validation" concern.  This language is not
sufficient, because validation most often occurs before a session is
originated.  Would you consider changing the latter part to:
"a description of how errors are returned"?

Will there be a BOF for ECRIT in Washington?

Brian

> -----Original Message-----
> From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency-
> bounces@ietf.org] On Behalf Of Peterson, Jon
> Sent: Monday, October 11, 2004 2:01 AM
> To: sipping-emergency@ietf.org
> Subject: [Sipping-emergency] New revision of proposed ECRIT charter
> 
> 
> All,
> 
> Here's a new version of the ECRIT charter for your consideration, that
> attempts to incorporate the discussion over the past couple of weeks.
> 
> Any further issues?
> 
> Jon Peterson
> NeuStar, Inc.
> 
> ---
> 
> Emergency Context  Resolution with Internet Technologies (ECRIT)
> 
> Transport Area Director(s):
> Allison Mankin <mankin@psg.com>
> Jon Peterson <jon.peterson@neustar.biz>
> 
> Transport Area Advisor: TBD
> 
> Working Group Chairs:  TBD
> 
> In a number of areas the public switched telephone network (PSTN)
> has been configured to recognize an explicitly specified number (commonly
> one that is short and easily memorized) as a call for emergency services.
> These numbers (e.g. 911, 112) 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.  These calls are intended to be
> delivered to
> special call  centers equipped to manage emergency response. 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.
> 
> 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.
> There
> are, however, Internet technologies available to describe location and to
> manage call routing.  This working group will describe when these may be
> appropriate
> and how they may be used.   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.
> 
> The group will show 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 response center. 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 other types of media
> streams. Video and text messaging, for example, might be used to request
> emergency services.
> 
> While this group anticipates a close working relationship with NENA, any
> solution
> presented must be useful regardless of jurisdiction, and it must be
> possible
> to
> use without a single, central authority.  Further, it must be possible for
> multiple
> delegations within a jurisdiction to be handled independently, as call
> routing
> for specific emergency types may be indepdent.
> 
> Deliverables:
> 
> Informational RFC containing terminology definitions and the requirements.
> 
> A BCP describing how to identify a session set-up request is to an
> emergency
> response center.
> 
> A BCP describing strategies for associating session originators with
> physical locations.
> 
> A BCP or Standards Track RFC describing how to route an emergency call
> based on location information.  Either within that document or as a
> separate
> document, a description of how error conditions are returned to the
> session
> originator and how to test for error conditions without activating an
> emergency
> response.  Privacy concerns related to that testing must be addressed
> in this document set.
> 
> A BCP describing how to discover the media stream types an ERC supports.
> 
> An Informational document describing the threats and security
> considerations.
> 
> 
> _______________________________________________
> Sipping-emergency mailing list
> Sipping-emergency@ietf.org
> https://www1.ietf.org/mailman/listinfo/sipping-emergency
> 

_______________________________________________
Sipping-emergency mailing list
Sipping-emergency@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-emergency