Re: [Ecrit] ECRIT WG Rechartering

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

Hi Brian, 

my reading of Milan's document was that he wanted to work on a solution
in that enables PSAP callbacks. 

See, for example, [REQ 4] at
http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-00.txt  

Ciao
Hannes

>-----Original Message-----
>From: ext Brian Rosen [mailto:[e-mail]] 
>Sent: 27 October, 2008 21:25
>To: Tschofenig, Hannes (NSN - FI/Espoo); 'ext James M. Polk'; 
>'Richard Barnes'
>Cc: 'ECRIT'
>Subject: RE: [Ecrit] ECRIT WG Rechartering
>
>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: [e-mail] [mailto:[e-mail]] 
>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:[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
>
>
_______________________________________________
Ecrit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ecrit