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

[Roger Marshall <[e-mail]>]

Hannes:
Thanks for your review and suggestions.  See inline.

-roger.

-----Original Message-----
From: Hannes Tschofenig [mailto:[e-mail]] 
Sent: Sunday, October 13, 2013 9:00 AM
To: Roger Marshall
Cc: ecrit_ietf.org; [e-mail]
Subject: Re: [Ecrit] Charter & Milestones update - Comments sought

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.

[rsm] suggested changes accepted.

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

[rsm] okay.

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

[rsm] changes will be made.

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

[rsm] true.  Status will be changed to Done.

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

[rsm] Yes, okay.

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]
> https://www.ietf.org/mailman/listinfo/ecrit