Re: [Ecrit] ECRIT WG Rechartering

["Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>]

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:[e-mail]] 
>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:[e-mail]>[e-mail]> 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:[e-mail]>[e-mail]
>>https://www.ietf.org/mailman/listinfo/ecrit
>>
>>
>>_______________________________________________
>>Ecrit mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/ecrit
>
>
_______________________________________________
Ecrit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ecrit