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

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 11 Oct 2004 02:00:43 -0400

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 <[email-masked]>
Jon Peterson <[email-masked]>

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/sipping-emergency

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 11 Oct 2004 08:57:00 -0400

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
> 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: [email-masked] [mailto:sipping-emergency-
> [email-masked]] On Behalf Of Peterson, Jon
> Sent: Monday, October 11, 2004 2:01 AM
> To: [email-masked]
> Subject: [Sipping-emergency] New revision of proposed ECRIT charter
> 
> 
> All,
>

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 11 Oct 2004 09:26:13 -0400

I like it.....I agree with Brian, we need to include EMTEL.

-Marc Linsner-

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Peterson, Jon
> 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.
> 
> ---
> 
> 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
> 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 
> 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:
> 
> A BCP describing how to identify a session set-up request is 
> to an emergency response center.
> 
> 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.
> 
> https://www1.ietf.org/mailman/listinfo/sipping> -emergency
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 11 Oct 2004 13:49:32 -0400

Looks good to me, seconding the comments made by others.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Oct 2004 16:43:41 -0400

Sounds good to me.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Tom Taylor <[email-masked]>
Date: Wed, 13 Oct 2004 17:50:00 -0400

I forgot to say I'm happy with the charter as rewritten.  I'll volunteer my 
services as chair or editor.

-- 
Tom Taylor
Carrier VoIP Standards Development
Nortel Networks
Phone +1 613 763 1496  (ESN 393-1496)
E-mail: [email-masked]