[Ecrit] meeting agenda, charter & milestone changes
Roger Marshall <RMarshall@telecomsys.com> Wed, 30 October 2013 15:48 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 89F4F21F9CE9 for <ecrit@ietfa.amsl.com>; Wed, 30 Oct 2013 08:48:05 -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=[AWL=-0.000, 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 7syQ2kQS-AZo for <ecrit@ietfa.amsl.com>; Wed, 30 Oct 2013 08:48:01 -0700 (PDT)
Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) by ietfa.amsl.com (Postfix) with ESMTP id 71B2E11E8250 for <ecrit@ietf.org>; Wed, 30 Oct 2013 08:47:51 -0700 (PDT)
Received: from SEA-EXCAS-1.telecomsys.com (exc2010-local1.telecomsys.com [10.32.12.186]) by sea-mx-01.telecomsys.com (8.14.5/8.14.5) with ESMTP id r9UFlhRg004928 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 30 Oct 2013 08:47:43 -0700
Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.31]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Wed, 30 Oct 2013 08:47:43 -0700
From: Roger Marshall <RMarshall@telecomsys.com>
To: "ecrit_ietf.org" <ecrit@ietf.org>
Thread-Topic: meeting agenda, charter & milestone changes
Thread-Index: Ac7Vg4it0ljI2Tb8S8KccPW7TGX+gA==
Date: Wed, 30 Oct 2013 15:47:42 +0000
Message-ID: <FBD5AAFFD0978846BF6D3FAB4C892ACC497054@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_FBD5AAFFD0978846BF6D3FAB4C892ACC497054SEAEXMB1telecomsy_"
MIME-Version: 1.0
Cc: "ecrit-chairs@tools.ietf.org" <ecrit-chairs@tools.ietf.org>
Subject: [Ecrit] meeting agenda, charter & milestone changes
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: Wed, 30 Oct 2013 15:48:18 -0000
Please see the agenda posted in the Meeting Materials Manager (and included below), http://www.ietf.org/proceedings/88/agenda/agenda-88-ecrit Note that the Milestones have been updated, while the Charter updates are under review by the ISB & IESG (revised version included at end). -roger marshall. *** ECRIT Agenda - 09:00-11:30, Monday, November 4, 2013 Vancouver 10 min * Agenda Bashing, Draft Status Update (Chairs) 20 min * Additional Data related to an Emergency Call (Hannes) http://www.ietf.org/id/draft-ietf-ecrit-additional-data-14.txt 15 min * Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (Brian) http://www.ietf.org/id/draft-ietf-ecrit-data-only-ea-06.txt 15 min * Updating Additional Data related to an Emergency Call using Subscribe/Notify (Brian) http://www.ietf.org/id/draft-rosen-ecrit-addldata-subnot-00.txt 10 min * A LoST extension to support return of complete and similar location info (Brian) http://www.ietf.org/id/draft-marshall-ecrit-similar-location-02.txt 20 min * Internet Protocol-based In-Vehicle Emergency Calls (Randy) 20 min * Next-Generation Pan-European eCall (Randy) Discussion *** Updated (as proposed) ECRIT Charter 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. 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] meeting agenda, charter & milestone chang… Roger Marshall