Re: [Ecrit] Charter & Milestones update - Comments sought

[Roger Marshall <[e-mail]>]

Based on text feedback from the list, I've updated the Charter text and Milestones.  See below.

(I've also included an attached file for redlined changes)

ECRIT charter (as revised):

Description of Working Group:

    In a number of areas, the public switched telephone network (PSTN) has
    been configured to recognize an explicitly specified number (usually
    one that is short and easily memorized) as a request for emergency
    services.  These numbers (e.g., 911, 112) are related to an emergency
    service context and depend on a broad, regional configuration of
    service contact methods and a geographically-constrained approach for
    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
    an association of both the physical location of the originating device
    along with appropriate call routing to an emergency service center.

    Calls placed using Internet technologies do not use the same systems
    Mentioned above to achieve those same goals, and the common use of
    overlay networks and tunnels (either as VPNs or for mobility) makes
    meeting these goals even more challenging.  There are, however,
    Internet technologies available to manage location and to perform call
    routing.  This working group will describe where and how these mechanisms
    may be used. The group will show how the availability of location data
    and call routing information at different steps in the call session
    setup would enable communication between a user and a relevant emergency
    response center. Though the term "call routing" is used,
    it should be understood that some of the mechanisms which will be
    described might be used to enable other types of media streams.

    Beyond human initiated emergency call request mechanisms, this group will
    develop new methods to request emergency assistance, such as sensor
    initiated emergency requests, and additional processes specified that
    address topics such as authentication of location, service URN definition
    and use, augmented information that could assist emergency call takers or
    responders.

    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 Internet, as opposed to government or military
    services that may impose very different authentication and routing
    requirements.

    While this group anticipates a close working relationship with groups
    such as NENA, EENA, 3GPP, and ETSI , any solution presented must be
    general enough to be potentially useful in or across multiple regions
    or jurisdictions, and it must be possible to use without requiring a
    single, central authority.  Further, it must be possible for multiple
    delegations within a jurisdiction to be handled independently, things
    such as call routing for specific emergency types, media types, language
    contents, etc.,  may be routed differently depending on established
    policies and availability.

    This working group cares about privacy and security concerns, and will
    address them within its documents.


Also, dependent on the above text, Gunnar has suggested the addition of the
following milestone:


xxx 2014 - Submit a draft 'Policy based routing in Emergency Services'



to the IESG for consideration as a Standards Track RFC


The complete Milestone list (as revised):

Done  Informational RFC containing terminology definitions and the requirements
Done  An Informational document describing the threats and security considerations
Done  A Standards Track RFC describing how to identify a session set-up request is to an emergency response center
Done  A Standards Track RFC describing how to route an emergency call based on location information
Done  An Informational document describing the Mapping Protocol Architecture
Done  Submit 'Location Hiding: Problem Statement and Requirements' to the IESG for consideration as an Informational RFC.
Done  Submit 'Framework for Emergency Calling using Internet Multimedia' to the IESG for consideration as an Informational RFC.
Done  Submit 'Best Current Practice for Communications Services in support of Emergency Calling' to the IESG for consideration as a BCP document
Done  Submit 'LoST Extension for returning Boundary Information for Services' to the IESG for consideration as an Experimental RFC
Done  Submit 'Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements' to the IESG for consideration as an Experimental RFC
Done    Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG  for consideration as an Informational RFC
Done    Submit 'Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices' to the IESG for consideration as a Standards Track RFC

Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for
consideration as an Informational RFC

Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call
Purposes' to the IESG for consideration as a Standards Track RFC

Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only
Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG for consideration as an
Experimental RFC

Dec 2013 - Submit a draft 'Policy for defining new service-identifying
labels' to the IESG for consideration as BCP

Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing'
to the IESG for consideration as an Informational RFC

Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services'
to the IESG for consideration as a Standards Track RFC


Dec 2014 - Submit a draft 'Policy based routing in Emergency Services'
to the IESG for consideration as a Standards Track RFC




From: [e-mail] [mailto:[e-mail]] On Behalf Of Gunnar Hellstrom
Sent: Sunday, October 13, 2013 4:53 PM
To: Gellens, Randall
Cc: [e-mail]
Subject: Re: [Ecrit] Charter & Milestones update - Comments sought

An addition could be made to this sentence:

"Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, as call routing for specific emergency types may be handled independently."

To

"Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, as call routing for specific emergency types, media types, language contents etc.  may be routed differently depending on established policies and availability."

And in the goals list include:



xxx 2014 - Submit a draft 'Policy based routing in Emergency Services'



to the IESG for consideration as a Standards Track RFC

Regards

Gunnar

________________________________
Gunnar Hellström
Omnitor
[e-mail]<mailto:[e-mail]>
[phone]
On 2013-10-13 19:22, Gellens, Randall wrote:

The current NENA document on policy-based routing only deals with legacy capabilities (that is, call diversion/exception handling).  The NENA group intends to produce a version two that covers NG9-1-1 (NENA i3) capabilities with the enhancements for call processing including media and other needs.



________________________________________

From: [e-mail]<mailto:[e-mail]> [[e-mail]<mailto:[e-mail]>] on behalf of Hannes Tschofenig [[e-mail]<mailto:[e-mail]>]

Sent: Sunday, October 13, 2013 9:50 AM

To: Gunnar Hellstrom

Cc: [e-mail]<mailto:[e-mail]>

Subject: Re: [Ecrit] Charter & Milestones update - Comments sought



Hi Gunnar,



that's fine with me but where do you want to add this remark in the

charter text Roger proposed?



Also, do we have any specific document in progress that is impacted by

policy based routing?



Ciao

Hannes





On 13.10.2013 19:37, Gunnar Hellstrom wrote:

Hi,

Policy based routing was once said to enable routing based on for

example media requirements and capabilities to specific PSAPs equipped

or educated for such calls.

In latest NENA spec for policy based routing, only PSAP availability is

mentioned as reason to route.



I do not remember that we have anything sufficiently explicit from IETF

on this topic, and suggest to include it in the goals.



Thanks,

Gunnar





------------------------------------------------------------------------

Gunnar Hellström

Omnitor

[e-mail]<mailto:[e-mail]>

[phone]

On 2013-10-13 11:59, Hannes Tschofenig wrote:

Hi Roger,



thanks for working on the updated charter text.



The text is fine for me; I only have a few minor suggestions.



On 04.10.2013 21:18, Roger Marshall wrote:

The ECRIT working group agreed that the chairs would propose updated

language to the wg charter, along with milestone data changes.



Compare this to the original charter found at:

http://tools.ietf.org/wg/ecrit/charters.



Please send your comments to the list, whether in favor, or with

alternative wording and/or dates.



Regards,



Roger Marshall/Marc Linsner



ECRIT Chairs



ECRIT charter (w/proposed revisions):



Description of Working Group:



In a number of areas, the public switched telephone network (PSTN) has



been configured to recognize an explicitly specified number (usually



one that is short and easily memorized) as a request for emergency



services. These numbers (e.g., 911, 112) are related to an emergency



service context and depend on a broad, regional configuration of



service contact methods and a geographically-constrained approach for



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



an association of both the physical location of the originating device



along with appropriate call routing to an emergency service center.



Calls placed using Internet technologies do not use the same systems



Mentioned above to achieve those same goals, and the common use of



overlay networks and tunnels (either as VPNs or for mobility) makes



meeting these goals even more challenging. There are, however,



Internet technologies available to manage location and to perform call



routing. This working group will describe where and how these mechanisms



may be used. The group will show how the availability of location data



and call routing information at different steps in the call 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.



I would omit this last sentence. I also believe that the term

"document" isn't appropriate here.







Beyond human initiated emergency call request mechanisms, this group

will



develop new methods to request emergency assistance, such as sensor



initiated emergency requests, and additional processes specified that



address topics such as authentication of location, service URN

definition



and use, augmented information that could assist emergency call

takers or



responders.



s/"authentication of location"/"trustworthy location"





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 Internet, as opposed to government or military



services that may impose very different authentication and routing



requirements.



While this group anticipates a close working relationship with groups



such as NENA and ETSI EMTEL, any solution presented must be useful



You should add "EENA" and "3GPP" here as well and replace ETSI EMTEL

with "ETSI" since we are now dealing also with other groups in ETSI in

addition to EMTEL.







regardless of jurisdiction, and it must be possible to use without

requiring 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 handled independently.



This working group cares about privacy and security concerns, and will



address them within its documents.



Milestones w/revised status/dates, as proposed



Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the

IESG



for consideration as an Informational RFC



Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for



consideration as an Informational RFC



Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call



Purposes' to the IESG for consideration as a Standards Track RFC



Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only



Emergency Alerts using the Session Initiation Protocol (SIP)' to the

IESG for consideration as an



Experimental RFC



Dec 2013 - Submit 'Extensions to the Emergency Services Architecture for



dealing with Unauthenticated and Unauthorized Devices' to the IESG for

consideration



I thought that this document has been sent to the IESG already.





as a Standards Track RFC



Dec 2013 - Submit a draft 'Policy for defining new service-identifying



labels' to the IESG for consideration as BCP



Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing'



to the IESG for consideration as an Informational RFC



Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services'



to the IESG for consideration as a Standards Track RFC



I believe you should also list all other concluded documents as well

(and mark them as done).





Ciao

Hannes







CONFIDENTIALITY NOTICE: The information contained in this message may be

privileged and/or confidential. If you are not the intended recipient,

or responsible for delivering this message to the intended recipient,

any review, forwarding, dissemination, distribution or copying of this

communication or any attachment(s) is strictly prohibited. If you have

received this message in error, please notify the sender immediately,

and delete it and all attachments from your computer and network.







_______________________________________________

Ecrit mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/ecrit



_______________________________________________

Ecrit mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/ecrit







_______________________________________________

Ecrit mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/ecrit



_______________________________________________

Ecrit mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/ecrit