Re: [Ecrit] ECRIT WG Rechartering

"Richard Barnes" <richard.barnes.ietf@gmail.com> Mon, 27 October 2008 13:39 UTC

Return-Path: <ecrit-bounces@ietf.org>
X-Original-To: ecrit-archive@megatron.ietf.org
Delivered-To: ietfarch-ecrit-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EDDE3A6AD0; Mon, 27 Oct 2008 06:39:47 -0700 (PDT)
X-Original-To: ecrit@core3.amsl.com
Delivered-To: ecrit@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E68693A6842 for <ecrit@core3.amsl.com>; Mon, 27 Oct 2008 06:39:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.739
X-Spam-Level:
X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnKHmoIpLmuf for <ecrit@core3.amsl.com>; Mon, 27 Oct 2008 06:39:45 -0700 (PDT)
Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by core3.amsl.com (Postfix) with ESMTP id 841353A6AE3 for <ecrit@ietf.org>; Mon, 27 Oct 2008 06:39:44 -0700 (PDT)
Received: by ug-out-1314.google.com with SMTP id b39so221230ugd.15 for <ecrit@ietf.org>; Mon, 27 Oct 2008 06:39:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=ZiWSycxRr2bGzTNkdgjr0nATBXXBvewQ5Ok7njgOtOE=; b=NF7iDCwsO1IQkpQjm/EQnz/DgPuTzsDJqnZKhMz/Gcpo8jC23hEh+0WwbZiwLuA1Yc yC7tmhmP8A/X6gq4VF68SIXJ/YhBGS1I+e0kCnNeeEEy9IrbLeWqAvfRAHsUZVfAyPIL HD17JC2cc+EFHAVzwgp5cS7X1PalqMZGHCZq4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=dc2KajTo7iaWWEIyzGK8x/6hcrQyRm9wEAiCM86jejFNoM7ntOTzpHPC71IDtBtFQc gIPPzq9JNYiMlYlTC7veKgrzXrW+C0QzdugVOVhJy6melg2KncNlfOO97ClgJi+kdsgY /Me50HQu2fHxjgqcAdPLBox/PQHoBFE6yym40=
Received: by 10.66.218.15 with SMTP id q15mr2053656ugg.77.1225114782737; Mon, 27 Oct 2008 06:39:42 -0700 (PDT)
Received: by 10.67.122.13 with HTTP; Mon, 27 Oct 2008 06:39:41 -0700 (PDT)
Message-ID: <c33e922d0810270639q4244b373pdafcd1ec33661f24@mail.gmail.com>
Date: Mon, 27 Oct 2008 17:39:41 +0400
From: Richard Barnes <richard.barnes.ietf@gmail.com>
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
In-Reply-To: <C41BFCED3C088E40A8510B57B165C162943512@FIESEXC007.nsn-intra.net>
MIME-Version: 1.0
References: <C41BFCED3C088E40A8510B57B165C162943512@FIESEXC007.nsn-intra.net>
Cc: ECRIT <ecrit@ietf.org>
Subject: Re: [Ecrit] ECRIT WG Rechartering
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/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>
Content-Type: multipart/mixed; boundary="===============0760795021=="
Sender: ecrit-bounces@ietf.org
Errors-To: ecrit-bounces@ietf.org

I think there are a few milestones missing from this charter:

-- A Standards-Track document describing how SIP messages related to
emergency calling are distinguished from other
messages(draft-patel-ecrit-sos-parameter)
3GPP have made it pretty clear (both on this list and last week at the
emergency services workshop) that this mechanism or something like it is a
requirement for their emergency calling system.

-- An Informational document describing requirements for emergency calling
by unregistered or unauthenticated devices.
(draft-schulzrinne-ecrit-unauthenticated access)
This is an issue that ECRIT has avoided for a long time, as other SDOs have
been developing mechanisms.  It would be useful to have an Internet-level
analysis to unify these lower-level approaches and guide their development.

-- An Informational document describing best practices for emergency
calling from autonomous devices (vs. human callers)
(draft-rosen-ecrit-ecall)
Lots of different organizations (e.g., EU eCall and OGC's sensor web) are
interested in having sensors or other devices place emergency calls.  These
efforts could be more interoperable and better aligned with the ECRIT
architecture if it were made explicit which subset of the ECRIT framework
these systems should use.

Cheers,
--Richard



On Tue, Oct 14, 2008 at 10:13 AM, Tschofenig, Hannes (NSN - FI/Espoo) <
hannes.tschofenig@nsn.com> wrote:

> Here is a first proposal for the ECRIT WG rechartering based on the
> discussions we had around IETF#72.
> For the moment, I have put 3 additional documents onto the charter:
> http://tools.ietf.org/id/draft-polk-ecrit-local-emergency-rph-namespace-
> 03.txt<http://tools.ietf.org/id/draft-polk-ecrit-local-emergency-rph-namespace-03.txt>
> http://tools.ietf.org/id/draft-barnes-ecrit-rough-loc-00.txt
> http://tools.ietf.org/id/draft-forte-ecrit-lost-extensions-00.txt
>
> Regarding the following two documents
> http://tools.ietf.org/id/draft-forte-ecrit-service-classification-00.txt
> http://tools.ietf.org/id/draft-sun-ecrit-shelter-service-00.txt
> I am waiting for additional feedback from the draft authors on how they
> perceive these documents should be progressed through the IETF, see my
> mail here:
> http://www.ietf.org/mail-archive/web/ecrit/current/msg05518.html
>
> Please take a look at it and give me feedback till the 21st October
> 2008.
>
> ------------------------------------------------------------------------
> ---------------------------
>
> Emergency Context Resolution with Internet Technologies (ecrit)
>
> Description of Working Group:
>
> 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. 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 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 independent.
>
> The group will work on the maintainance of the
> Location-to-Service Translation (LoST) protocol, on (emergency services
> and non-emergency services related)extensions to LoST to the as well as
> on necessary extension related to emergency call routing.
>
> This working group cares about privacy and security concerns, and will
> address them within its documents.
>
> Goals and Milestones:
>
> Done            An 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
> Dec 2008        An Informational document describing the ECRIT Framework
> Dec 2008        A BCP document describing the emergency call support for
> devices
> Oct 2008        An Informational document providing a problem statement
> and requirements for location hiding
> Oct 2008        An Informational document specifying how to express
> holes in LoST service boundaries
> Dec 2008        An Informational document describing how to synchronize
> LoST servers
> Jan 2009        A Standards Track RFC registering a SIP Resource
> Priority Header Namespace for Local Emergency Communications
> Feb 2009        An Informational document describing how imprecise
> location is used for emergency context resolution
> Feb 2009        A Standards Track RFC containing Location-to-Service
> Translation Protocol (LoST) Extensions
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit