1. ECRIT IETF 72 July 2008 Dublin Hannes Tschofenig Marc Linsner Roger Marshall

2. Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: -the IETF plenary session, -any IETF working group or portion thereof, -the IESG or any member thereof on behalf of the IESG, -the IAB or any member thereof on behalf of the IAB, -any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, -the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3978 (updated by RFC 4748) and RFC 3979(updated by RFC 4879). Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3978 (and RFC 4748) for details. A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best Current Practices RFCs and IESG Statements. A participant in any IETF activity acknowledges that written, audio and video records of meetings may be made and may be available to the public.

3. Agenda  Agenda Bashing  Status - Chairs  draft-ietf-ecrit-lost-10 (RFC Editor's queue)  draft-ietf-ecrit-mapping-arch-03 (IESG Evaluation :: AD Followup)  draft-ietf-ecrit-dhc-lost-discovery-03.txt (RFC Editor's queue)  Framework and Phone – Brian Rosen  draft-ietf-ecrit-framework-06  draft-ietf-ecrit-phonebcp-05  Ongoing Work – Henning Schulzrinne  DISCUSS on draft-ietf-ecrit-mapping-arch-03  draft-ietf-ecrit-lost-sync-00  draft-ietf-ecrit-location-hiding-requirements-00  draft-ietf-ecrit-specifying-holes-00

4. Agenda (con’t)  Re-chartering?  draft-polk-ecrit-local-emergency-rph-namespace-03 (updated)  draft-barnes-ecrit-rough-loc-00 (unchanged)  draft-schulzrinne-ecrit-unauthenticated-access-03  draft-norreys-ecrit-authority2individuals-requirements-01 (updated)  draft-forte-ecrit-lost-extensions-00 (new indiv)  draft-forte-ecrit-service-classification-00 (new indiv)  draft-robins-ecrit-sub-services-00 (new)  draft-rosen-ecrit-ecall-01 (new)  draft-sun-ecrit-shelter-service-00 (new)  draft-sun-ecrit-unsafe-areas-00 (new)  draft-tschofenig-ecrit-trustworthy-location-00 (new)  draft-wolf-ecrit-lost-servicelistboundary-00 (new)

5. External (to ECRIT) 5th SDO Emergency Service Coordination Workshop –October 21-23, 2008 –Vienna, Austria –Host: Frequentis –http://www.emergency-services-coordination.info/http://www.emergency-services-coordination.info/

6. draft-polk-ecrit-local-emergency-rph-namespace-03 This document creates and IANA registers the new Session Initiation Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for local emergency usage to a public safety answering point (PSAP), between PSAPs, and between a PSAP and first responders and their organizations.

7. draft-barnes-ecrit-rough-loc-00 Emergency calling works best when precise location is available for emergency call routing. However, there are situations in which a location provider is unable or unwilling to provide precise location, yet still wishes to enable subscribers to make emergency calls. This document describes the level of location accuracy that providers must provide to enable emergency call routing. In addition, we descibe how emergency services and non-emergency services can be invoked by an endpoint that does not have access to its precise location.

8. draft-schulzrinne-ecrit-unauthenticated-access-03 The IETF emergency services architecture assumes that access to a network has already happened using the traditional network access authentication procedures or that no authentication for network access is needed (e.g., in case of public hotspots). Subsequent protocol interactions, such as obtaining location information, learning the address of the Public Safety Answering Point (PSAP) and the emergency call itself are largely decoupled from the underlying network access procedures. There are, however, cases where a device is not in possession of credentials for network access, does not have a VoIP provider, or where the credentials are available but became invalid due to various reasons (e.g., credit exhaustion, expired accounts, etc.). This document provides a problem statement, introduces terminology and describes an extension for the base IETF emergency services architecture.

9. draft-norreys-ecrit-authority2individuals-requirements-01 Public safety agencies need to provide information to the general public before and during large-scale emergencies. While many aspects of such systems are specific to national or local jurisdictions, emergencies span such boundaries and notifications need to reach visitors from other jurisdictions. This document summarizes requirements for protocols to alert individuals within a defined geographic area.

10. draft-forte-ecrit-lost-extensions-00 An important class of location-based services answer the question "What instances of this service are closest to me?" Examples include finding restaurants, gas stations, stores, automated teller machines, wireless access points (hot spots) or parking spaces. Currently, the Location-to-Service Translation (LoST) protocol only supports mapping locations to a single service based on service regions. This document describes an extension that allows queries "N nearest" and "within distance X".

11. draft-forte-ecrit-service-classification-00 This document creates a registry for describing the types of services available at a specific location. The registry is then referenced by other protocols that need a common set of service terms as protocol constants. In particular, we define location-based service as either a point at a specific geographic location (e.g., bus stop) or a service covering a specific region (e.g., pizza delivery)

12. draft-robins-ecrit-sub-services-00 This document describes, how a LoST client can ask LoST server for the list of sub services that it supports, and to incorporate additional information about the service provider in response.

13. draft-rosen-ecrit-ecall-01 This document describes how to use a subset of the IETF-based emergency call framework for accomplishing emergency calling support in vehicles. Simplifications are possible due to the nature of the functionality that is going to be provided in vehicles with the usage of GPS. Additionally, further profiling needs to be done regarding the encoding of location information.

14. draft-sun-ecrit-shelter-service-00 This document defines a new service registration 'shelter', and describes how to find, what instances of shelter service are closest to the user's location.

15. draft-sun-ecrit-unsafe-areas-00 This document describes how to specify unsafe areas in LoST for emergency services, such as police, mountain, marine and fire.

16. draft-tschofenig-ecrit-trustworthy-location-00 For location-based applications, such as emergency calling or roadside assistance, the identity of the requestor is less important than accurate and trustworthy location information. A number of protocols are available to supply end systems with either civic or geodetic information. For some applications it is an important requirement that location information has not been modified in transit or by the end point itself. This document investigates different threats, the adversary model, and outlines three possible solutions. The document concludes with a suggestion on how to move forward.

17. draft-wolf-ecrit-lost-servicelistboundary-00 LOST is able to map service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a query to the LoST server. However, the response from the LoST server does not give information about the geographical region, for which the returned service list is valid. Therefore this document proposes a ServiceListBoundary, in addition to the ServiceBoundary (which indicates the region a specific service URL is valid).

18. Potential Charter LoST Maintenance and Extensions for Emergency Services LoST Extensions for non-Emergency Services Emergency Services Extensions –Corrections learned via implementations Authority-to-Citizen Emergency Services –Requirements draft –Architecture draft –Protocol draft (if needed)