Re: [Ecrit] ECRIT WG Rechartering

["James M. Polk" <[e-mail]>]

At 01:38 PM 10/27/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>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

these are kinda held back by the idea of refusing the BYE discussion, 
aren't they?


> >-----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