Subject: [Ecrit] ECRIT WG Rechartering

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 14 Oct 2008 09:13:27 +0300

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-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
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 14 Oct 2008 09:06:34 -0500

Hi, Hannes,

Could you say anything about the future of authority-to-citizen emergency 
services work mentioned during the "potential charter" discussion in Dublin?

Thanks,

Spencer

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 14 Oct 2008 20:33:25 +0300

Good question, Spencer. 

Here is the story: During the IETF#72 ECRIT meeting we said that we
would request a longer slot for ECRIT and then use one part of the
meeting to discuss the next steps regarding the authority-to-citizen
given that we got good feedback from a previous adhoc meeting (I guess
that was in the Chicago IETF). 

Brian and Steve were nominated to organize this early warning session. 

Anyway, when I wanted to request a longer slot for ECRIT but Cullen
suggested to schedule a separate (official) BOF instead. As such, Marc
and I changed our request to a small slot for ECRIT and Brian and Steve
started their work on the charter proposal for the BOF. For some reason
they haven't sent the text to the list yet and I might not even have the
latest version. The BOF is listed on the scheduled BOF page (see
http://trac.tools.ietf.org/bof/trac/wiki) and I was hoping to see some
mails from Brian/Steve sometime soon. 

Since the BOF did not take place yet there is obviously no decision on
whether that work should be done in the IETF at all and in what group
(if at all). 

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Spencer Dawkins
>Sent: 14 October, 2008 17:07
>To: ECRIT
>Subject: Re: [Ecrit] ECRIT WG Rechartering
>
>Hi, Hannes,
>
>Could you say anything about the future of 
>authority-to-citizen emergency services work mentioned during 
>the "potential charter" discussion in Dublin?
>
>Thanks,
>
>Spencer
>
>
>http://tools.ietf.org/id/draft-forte-ecrit-service-classification-00.t
>> xt 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:
>> 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.
>>

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 14 Oct 2008 13:26:57 -0500

>http://tools.ietf.org/id/draft-polk-ecrit-local-emergency-rph-namespace-

I'll have a new version before the -00 deadline. Can either of you 
chairs submit to the Secretariat that

         draft-ietf-ecrit-local-emergency-rph-namespace-00

is coming and approved by the chairs (so we don't end up with a timing issue)?

Thanks

James

---

From: "Richard Barnes" <[email-masked]>
Date: Mon, 27 Oct 2008 17:39:41 +0400

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) <
[email-masked]> wrote:

> 03.txt<http://tools.ietf.org/id/draft-polk-ecrit-local-emergency-rph-namespace-03.txt>

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 27 Oct 2008 13:35:59 -0500

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

>On Tue, Oct 14, 2008 at 10:13 AM, Tschofenig, Hannes (NSN - 
>FI/Espoo) <<mailto:[email-masked]>[email-masked]> wrote:
><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-forte-ecrit-lost-extensions-00.txt>http://tools.ietf.org/id/draft-forte-ecrit-lost-extensions-00.txt
>
><http://tools.ietf.org/id/draft-forte-ecrit-service-classification-00.txt>http://tools.ietf.org/id/draft-forte-ecrit-service-classification-00.txt
><http://www.ietf.org/mail-archive/web/ecrit/current/msg05518.html>http://www.ietf.org/mail-archive/web/ecrit/current/msg05518.html
>
><mailto:[email-masked]>[email-masked]

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 27 Oct 2008 20:38:02 +0200

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 

>From: ext James M. Polk [mailto:[email-masked]] 
>Sent: 27 October, 2008 20:36
>To: Richard Barnes; Tschofenig, Hannes (NSN - FI/Espoo)
>Cc: ECRIT
>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.
>
>
>>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.
>>
>>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
>>
>>
>>
>>FI/Espoo) 
><<mailto:[email-masked]>[email-masked]> wrote:
>><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-forte-ecrit-lost-extensions-00
>.txt>http
>>://tools.ietf.org/id/draft-forte-ecrit-lost-extensions-00.txt
>>
>><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
>><http://www.ietf.org/mail-archive/web/ecrit/current/msg05518.h
>tml>http:
>>//www.ietf.org/mail-archive/web/ecrit/current/msg05518.html
>>
>>--------------------------------------------------------------
>---------
>>-
>>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 
>>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.
>>
>>Translation (LoST) protocol, on (emergency services and non-emergency

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 27 Oct 2008 15:25:01 -0400

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: [email-masked] [mailto:[email-masked]] 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

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 27 Oct 2008 21:29:57 +0200

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

>From: ext Brian Rosen [mailto:[email-masked]] 
>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
>
>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
>
>On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
>We in the group can make decisions at any time regardless of 
>what was presented at the meeting. 
>>(Henning's) has been presented to the WG.  That usually limits their 
>>ability to be a WG item yet.
>>
>>

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 27 Oct 2008 15:56:52 -0500

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

> >><http://tools.ietf.org/id/draft-polk-ecrit-local-emergency-rph>-namespac
> >><http://tools.ietf.org/id/draft-forte-ecrit-lost-extensions-00>.txt>http
> >><http://tools.ietf.org/id/draft-forte-ecrit-service-classifica>tion-00.t
> >><http://www.ietf.org/mail-archive/web/ecrit/current/msg05518.h>tml>http:

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 28 Oct 2008 13:43:27 +0200

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

Nope. As mentioned in the initial plan for Phone BCP we would delete the
sentence about not sending a BYE. 

FINISH the document.