Re: [Ecrit] ECRIT WG Rechartering

"Brian Rosen" <br@brianrosen.net> Mon, 27 October 2008 19:25 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 47A843A67D4; Mon, 27 Oct 2008 12:25:26 -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 2639F3A6BB0 for <ecrit@core3.amsl.com>; Mon, 27 Oct 2008 12:25:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.53
X-Spam-Level:
X-Spam-Status: No, score=-0.53 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, MANGLED_EMRG=2.3]
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 3MPo8LxtqSZv for <ecrit@core3.amsl.com>; Mon, 27 Oct 2008 12:25:19 -0700 (PDT)
Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 2F8B43A6BB1 for <ecrit@ietf.org>; Mon, 27 Oct 2008 12:25:13 -0700 (PDT)
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from <br@brianrosen.net>) id 1KuXi4-0006oI-8X; Mon, 27 Oct 2008 14:25:04 -0500
From: Brian Rosen <br@brianrosen.net>
To: "'Tschofenig, Hannes (NSN - FI/Espoo)'" <hannes.tschofenig@nsn.com>, "'ext James M. Polk'" <jmpolk@cisco.com>, 'Richard Barnes' <richard.barnes.ietf@gmail.com>
References: <C41BFCED3C088E40A8510B57B165C162943512@FIESEXC007.nsn-intra.net> <c33e922d0810270639q4244b373pdafcd1ec33661f24@mail.gmail.com> <XFE-RTP-202H71yEXUI000001a2@xfe-rtp-202.amer.cisco.com> <C41BFCED3C088E40A8510B57B165C162A5D89C@FIESEXC007.nsn-intra.net>
In-Reply-To: <C41BFCED3C088E40A8510B57B165C162A5D89C@FIESEXC007.nsn-intra.net>
Date: Mon, 27 Oct 2008 15:25:01 -0400
Message-ID: <014501c93869$b741bcb0$25c53610$@net>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ack4Yt7/xf6mXN7zQXq8uLxQ03WhmAAAB+CAAAGiPAA=
Content-Language: en-us
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Source:
X-Source-Args:
X-Source-Dir:
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ecrit-bounces@ietf.org
Errors-To: ecrit-bounces@ietf.org

Another item that I think deserves some chartered work is PSAP call backs.
There are a number of issues that have been raised about how call backs
work, including marking, services that might be affected (for example,
consider call forwarding), and any kind of priority mechanisms that might be
applied.

Brian

-----Original Message-----
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of
Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Monday, October 27, 2008 2:38 PM
To: ext James M. Polk; Richard Barnes
Cc: ECRIT
Subject: Re: [Ecrit] ECRIT WG Rechartering

We in the group can make decisions at any time regardless of what was
presented at the meeting. 
I believe we should speed up a bit with our work. 

I also hope that you and Brian are going to update the
PhoneBCP/Framework document so that we get that document out of our way 

>-----Original Message-----
>From: ext James M. Polk [mailto:jmpolk@cisco.com] 
>Sent: 27 October, 2008 20:36
>To: Richard Barnes; Tschofenig, Hannes (NSN - FI/Espoo)
>Cc: ECRIT
>Subject: Re: [Ecrit] ECRIT WG Rechartering
>
>At 08:39 AM 10/27/2008, Richard Barnes wrote:
>>I think there are a few milestones missing from this charter:
>
>I think, but could be wrong, that only one of these IDs 
>(Henning's) has been presented to the WG.  That usually limits 
>their ability to be a WG item yet.
>
>
>>-- 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) 
><<mailto:hannes.tschofenig@nsn.com>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
>-namespac
>>e-03.txt>http://tools.ietf.org/id/draft-polk-ecrit-local-emerg
>ency-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>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-classifica
>tion-00.t
>>xt>http://tools.ietf.org/id/draft-forte-ecrit-service-classifi
>cation-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.h
>tml>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
>><mailto:Ecrit@ietf.org>Ecrit@ietf.org
>>https://www.ietf.org/mailman/listinfo/ecrit
>>
>>
>>_______________________________________________
>>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

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit