ECRIT

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 (cont)

• 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-requirem
  ents-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/

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-requirem
ents-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 ltlistServicesByLocationgt 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)