[Ecrit] Charter & Milestones update - Comments sought

Roger Marshall <RMarshall@telecomsys.com> Fri, 04 October 2013 18:18 UTC

Return-Path: <RMarshall@telecomsys.com>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324F521F9AA8 for <ecrit@ietfa.amsl.com>; Fri, 4 Oct 2013 11:18:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level:
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+LYUswJV9UQ for <ecrit@ietfa.amsl.com>; Fri, 4 Oct 2013 11:18:15 -0700 (PDT)
Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) by ietfa.amsl.com (Postfix) with ESMTP id 091D621F99CD for <ecrit@ietf.org>; Fri, 4 Oct 2013 11:18:14 -0700 (PDT)
Received: from SEA-EXCAS-2.telecomsys.com (exc2010-local2.telecomsys.com [10.32.12.187]) by sea-mx-02.telecomsys.com (8.14.5/8.14.5) with ESMTP id r94II3oj012213 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 4 Oct 2013 11:18:03 -0700
Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.185]) by SEA-EXCAS-2.telecomsys.com ([10.32.12.187]) with mapi id 14.01.0218.012; Fri, 4 Oct 2013 11:18:03 -0700
From: Roger Marshall <RMarshall@telecomsys.com>
To: "ecrit_ietf.org" <ecrit@ietf.org>
Thread-Topic: Charter & Milestones update - Comments sought
Thread-Index: Ac7BLfNZgOHANmOzQNGU4fpZSblfKQ==
Date: Fri, 04 Oct 2013 18:18:01 +0000
Message-ID: <FBD5AAFFD0978846BF6D3FAB4C892ACC45811B@SEA-EXMB-1.telecomsys.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.32.12.134]
Content-Type: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC45811BSEAEXMB1telecomsy_"
MIME-Version: 1.0
Subject: [Ecrit] Charter & Milestones update - Comments sought
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ecrit>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Oct 2013 18:18:19 -0000

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.

    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 and ETSI EMTEL, any solution presented must be useful
    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
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


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.