Subject: [Ecrit] ECRIT Rechartering & Milestone Update

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 17 Aug 2009 21:30:45 +0300

Hi all, 

please let us know if there is something incorrect or missing with the
proposal for the new charter & milestones. 

Ciao
Hannes & Marc

----------------

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.
Explicitly outside the scope of this group is the question of
pre-emption or prioritization of emergency services traffic. 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.

The group will maintain and extend the Location to Service Translation 
(LoST) protocol for emergency services related aspects but also for 
usage outside the emergency services context. Additionally, the group
is chartered to work on descriptions and extensions regarding
citizen-to-authority services (such as defining a Resource Priority 
header for usage with emergency services). 

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.

This working group cares about privacy and security concerns, and will
address them within its documents.

Goals and Milestones:

Done     Submit "Requirements for Emergency Context Resolution with
Internet Technologies" to the IESG for consideration as an Informational
RFC 

Done     Submit "Security Threats and Requirements for Emergency Call
Marking and Mapping" to the IESG for consideration as an Informational
RFC

Done     Submit "A Uniform Resource Name (URN) for Emergency and Other
Well-Known Services" to the IESG for consideration as a Standards Track
RFC 

Done     Submit "LoST: A Location-to-Service Translation Protocol" to
the IESG for consideration as a Standards Track RFC

Done     Submit "Discovering LoST Servers Using DHCP" to the IESG for
consideration as Informational RFC

Done     Submit "Location-to-URL Mapping Architecture and Framework" to
the IESG for consideration as an Informational RFC

Done     Submit "Location Hiding: Problem Statement and Requirements" to
the IESG for consideration as an Informational RFC

Done     Submit "Specifying Holes in LoST Service Boundaries" to the
IESG for consideration as a BCP RFC

Done Submit "Best Current Practice for Communications Services in
support of Emergency Calling" to the IESG for consideration as a BCP RFC

Done Submit "Framework for Emergency Calling using Internet
Multimedia" to the IESG for consideration as a Standards Track RFC

Aug 2009 Submit "Synchronizing Location-to-Service Translation (LoST)
Servers" to the IESG for consideration as a Standards Track RFC

Sep 2009 Submit "IANA Registering a SIP RPH Namespace for Local
Emergency Communications" to the IESG for consideration as a Standards
Track RFC

Oct 2009 Submit "LoST ServiceListBoundary Extension" to the IESG for 
consideration as an Experimental RFC 

Nov 2009 Submit "RFC 5031bis" to the IESG for consideration as a
Standards Track RFC

Dec 2009 Submit "Location-to-Service Translation Protocol (LoST)
Extensions" to the IESG for consideration as an Informational RFC

Feb 2010 Submit "Using Imprecise Location for Emergency Context
Resolution" to the IESG for consideration as an Informational RFC

Mar 2010 Submit "Marking of Calls initiated by Public Safety 
Answering Points (PSAPs)" to the IESG for consideration as an 
Informational RFC

Apr 2010 Submit "Emergency Services Architecture Extensions for
Unauthenticated and Unauthorized Devices" to the IESG for 
consideration as an Experimental RFC

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 18 Aug 2009 11:06:06 -0500

>proposal for the new charter & milestones.

thanks for this ID a milestone

>Answering Points (PSAPs)" to the IESG for consideration as an

I'm unfamiliar with either of these two IDs -- as individual or WG 
items.  Looking at the tools page, it doesn't appear that either one 
exists yet, even as individual IDs. Can someone point me to either ID?

I don't remember either topic being discussed in Stockholm, but I 
could have been distracted.

James

>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 18 Aug 2009 19:48:30 +0300

Hey James, 

>thanks for this ID a milestone

We would have added it sooner but ... 

>Answering 
>>Points (PSAPs)" to the IESG for consideration as an Informational RFC
>
>I'm unfamiliar with either of these two IDs -- as individual 
>or WG items.  Looking at the tools page, it doesn't appear 
>that either one exists yet, even as individual IDs. Can 
>someone point me to either ID?

RFC 5031bis refers to this document: 
http://tools.ietf.org/id/draft-forte-ecrit-service-urn-policy-00.txt

We discussed the requirements for some time and now there is also a document
available. 

The second document can be found here: 
http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback-00.txt

Since we only had a discussion about the problem, requirements and design
choices but have not decided about the solution approach I put the milestone
far out there (and that also provides us a chance for "load balancing"). 

(We had a HUM about both these documents in past meetings.)

>I don't remember either topic being discussed in Stockholm, 
>but I could have been distracted.

We had them on the initial agenda for the meeting but then Henning did not
participate and I got ill. The meeting time was still used in a good
fashion, I believe. 

Ciao
Hannes

PS: Another thing I should also mention that Marc and I would like to
involve more folks with the chartered items to ensure continues progress.
So, if everyone in the group has time available to help with the chartered
items please let us know. We will post a mail about this in a separate mail.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 18 Aug 2009 12:08:46 -0500

>We would have added it sooner but ...

<mumble>

>We discussed the requirements for some time and now there is also a document

I knew about this doc, but didn't understand this is being talked 
about as a formal "bis" ID (i.e., that it would obsolete 5031).  If 
that's the case (which I think you just said it is), then shouldn't 
the filename change to

         draft-forte-ecrit-5031bis-00.txt

?

This does make its intentions much more clear for everyone to understand.

>(We had a HUM about both these documents in past meetings.)

I guess I didn't understand Forte's ID was replacing 5031, is all.

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 19 Aug 2009 08:46:59 +0300

I forgot to indicate a deadline. 

Let's pick September 2nd. 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Hannes Tschofenig
>Sent: 17 August, 2009 21:31
>To: 'ecrit'
>Subject: [Ecrit] ECRIT Rechartering & Milestone Update
>
>Hi all, 
>
>please let us know if there is something incorrect or missing 
>with the proposal for the new charter & milestones. 
>
>Ciao
>Hannes & Marc
>
>----------------
>
>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 
>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.
>pre-emption or prioritization of emergency services traffic. 
>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.
>
>(LoST) protocol for emergency services related aspects but 
>also for usage outside the emergency services context. 
>Additionally, the group is chartered to work on descriptions 
>and extensions regarding citizen-to-authority services (such 
>as defining a Resource Priority header for usage with 
>emergency services). 
>
>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.
>
>This working group cares about privacy and security concerns, 
>and will address them within its documents.
>
>Goals and Milestones:
>
>Internet Technologies" to the IESG for consideration as an 
>Informational RFC 
>
>Marking and Mapping" to the IESG for consideration as an 
>Informational RFC
>
>Well-Known Services" to the IESG for consideration as a 
>Standards Track RFC 
>
>Done Submit "Best Current Practice for Communications Services 
>in support of Emergency Calling" to the IESG for consideration 
>as a BCP RFC
>
>Aug 2009 Submit "Synchronizing Location-to-Service Translation 
>(LoST) Servers" to the IESG for consideration as a Standards Track RFC
>
>Sep 2009 Submit "IANA Registering a SIP RPH Namespace for 
>Local Emergency Communications" to the IESG for consideration 
>as a Standards Track RFC
>
>Oct 2009 Submit "LoST ServiceListBoundary Extension" to the 
>IESG for consideration as an Experimental RFC 
>
>Nov 2009 Submit "RFC 5031bis" to the IESG for consideration as 
>a Standards Track RFC
>
>Dec 2009 Submit "Location-to-Service Translation Protocol 
>(LoST) Extensions" to the IESG for consideration as an 
>Informational RFC
>
>Feb 2010 Submit "Using Imprecise Location for Emergency 
>Context Resolution" to the IESG for consideration as an 
>Informational RFC
>
>Apr 2010 Submit "Emergency Services Architecture Extensions 
>for Unauthenticated and Unauthorized Devices" to the IESG for

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 19 Aug 2009 09:02:07 +0300

Hi James, 
 
>>We discussed the requirements for some time and now there is also a 
>>document available.
>
>I knew about this doc, but didn't understand this is being 
>talked about as a formal "bis" ID (i.e., that it would 
>obsolete 5031).  If that's the case (which I think you just 
>said it is), then shouldn't the filename change to
>

Good point. This document actually only updates RFC 5031. It does not
replace it. 
So, we shouldn't really call it -bis. 

Ciao
Hannes

---

From: Robins George <[email-masked]>
Date: Wed, 19 Aug 2009 14:15:59 +0800

Hannes,

> Extensions" to the IESG for consideration as an Informational RFC
Did you skip the shelter draft ?
http://tools.ietf.org/html/draft-sun-ecrit-shelter-service-02

-- Robins

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 19 Aug 2009 09:22:57 +0300

Nope, I did not. 

Per discussion some time ago the idea was to change the Service URN
allocation policy and to have documents like this to be submitted to the RFC
Editor.  

>From: Robins George [mailto:[email-masked]] 
>Sent: 19 August, 2009 09:16
>To: Hannes Tschofenig
>Cc: 'ecrit'
>Subject: Re: [Ecrit] ECRIT Rechartering & Milestone Update
>
>Hannes,
>

---

From: Robins George <[email-masked]>
Date: Wed, 19 Aug 2009 16:53:54 +0800

Hannes,

Thanks for the clarification.
I would like to know, when can we submit this draft to RFC Editor ?

-- Robins

>> Subject: Re: [Ecrit] ECRIT Rechartering&  Milestone Update
>>
>> Hannes,
>>
>>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 21 Aug 2009 08:56:46 +0300

First, we have to get the charter and the milestones updated. In about 2
weeks I plan to send the charter/milestone proposal (with the feedback
from the list incorporated) to the IESG. Then, they will discuss it and
other folks will comment on it. That takes a bit of time. 

Then, we hopefully have the new charter. One of the items is the Service
URN update that will allow us to simplify the allocation of new Service
URNs. Your document creates such a service URN.

At this point in time you can submit your draft to the RFC Editor.
Hopefully by that time the Service URN document will be progressed to an
RFC and the new policy is in place. 

The policy currently asks for expert review. Your document will then be
sent for expert review (the IESG will appoint an expert reviewer, most
likely from this group). 

After the expert review your document will go through the normal
processing steps through the publication process. 

Ciao
Hannes

PS: I would appreciate if you could review other working group items as
well so that we progress our work faster and consequently your document
will go through the pipeline faster as well. 

>On Behalf Of ext Robins George
>Sent: 19 August, 2009 11:54
>To: Hannes Tschofenig
>Cc: 'ecrit'
>> allocation policy and to have documents like this to be submitted to 
>> the RFC Editor.
>>
>>