[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
geopriv                                                         B. Rosen
Internet-Draft                                                 Emergicom
Expires: August 19, 2005                                       N. Abbott
                                                               Telcordia
                                                       February 15, 2005


              NENA Requirements for Extensions to PIDF-LO
              draft-rosen-nena-geopriv-requirements-00.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 19, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The National Emergency Number Association (NENA)'s mission is to
   foster the technological advancement, availability, and
   implementation of a universal emergency telephone number system in
   North America.  In our efforts to support emergency calls coming over
   the Internet, we have identified several issues with the present



Rosen & Abbott           Expires August 19, 2005                [Page 1]


Internet-Draft              NENA Requirements              February 2005


   definition of the PIDF-LO object.  We present our requirements to
   address these shortcomings.

Table of Contents

   1.   Requirements notation  . . . . . . . . . . . . . . . . . . . . 3
   2.   Additional Requirements  . . . . . . . . . . . . . . . . . . . 4
   3.   Security Considerations  . . . . . . . . . . . . . . . . . . . 6
   4.   References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6
        Intellectual Property and Copyright Statements . . . . . . . . 7








































Rosen & Abbott           Expires August 19, 2005                [Page 2]


Internet-Draft              NENA Requirements              February 2005


1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].














































Rosen & Abbott           Expires August 19, 2005                [Page 3]


Internet-Draft              NENA Requirements              February 2005


2.  Additional Requirements

   Req-1: When location is forged, responder resources are
          inappropriately dispatched.  The location must be
          authenticated by its source and verified by the PSAP.  This
          implies a digital signature on the location object.  There are
          implications when location is presented to an entity in a form
          other than PIDF-LO.  For example, if an endpoint learns its
          location from DHCP, the source of the location must sign it in
          such a way that it can be transported by DHCP, converted to
          PIDF-LO, transported by a using protocol, and subsequently
          have the digital signature validated.
   Req-2: If there is more than one set of location information is
          provided in the PIDF-LO, guidelines/policy are needed to
          assist in selecting the appropriate location information to be
          used for emergency call routing and dispatch.
   Req-3: Two community names must be supported (postal and legal).
   Req-4: The "DateTimeStamp" defined in PIDF-LO is insufficient for our
          needs.  We need to know when the location was determined.
          That may or not be when the PIDF-LO document was created.
   Req-5: Confidence and Uncertainty must be expanded.  Two single
          component values are proving to be insufficient.  We will
          bring a proposal to improve the ability to specify these
          quantities.
   Req-6: "Placetype" must be expanded (does this really need to go to
          SIMPLE?)
   Req-7: If there is more than one set of location information is
          provided in the PIDF-LO, guidelines/policy are needed to
          assist in selecting the appropriate location information to be
          used for emergency call routing and dispatch.
   Req-8: It is desirable to have fall-back location information that
          can be used to determine default routing of emergency calls
          (e.g., if the specific location information is not currently
          represented in the available routing data base).
   Req-9: Other information, e.g., associated with the "caller" or the
          caller's location, may also be useful to the emergency
          responder, but which is more appropriately maintained by the
          user, than by a provider of physical, geographical location
          information.  A mechanism to include or refer to such
          additional information is needed.  (This may really need to be
          considered by SIMPLE?) However, such information may need to
          build on the privacy mechanisms defined by Geopriv for
          location information.  For example, emergency responders today
          may have access to information about disabilities of potential
          callers in a particular location that will assist emergency
          responders in taking special response measures.  Examples of
          the kind of information that might be helpful include:




Rosen & Abbott           Expires August 19, 2005                [Page 4]


Internet-Draft              NENA Requirements              February 2005


          *  Life Support System in use
          *  Oxygen in use
          *  Mobility Impaired
          *  Blind
          *  Hearing Impaired
          *  Teletypwriter
          *  Speech Impaired
          *  Developmentally disabled..











































Rosen & Abbott           Expires August 19, 2005                [Page 5]


Internet-Draft              NENA Requirements              February 2005


3.  Security Considerations

   None.

4.  References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.


Authors' Addresses

   Brian Rosen
   Emergicom
   470 Conrad Dr
   Mars, PA  16046
   US

   Phone: +1 724 382 1051
   Email: br@brianrosen.net


   Nadine Abbott
   Telcordia
   One Telcordia Drive, Room 4B655
   Piscataway, NJ  08854
   US

   Phone: +1-732-699-6109
   Email: nabbott@telcordia.com





















Rosen & Abbott           Expires August 19, 2005                [Page 6]


Internet-Draft              NENA Requirements              February 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Rosen & Abbott           Expires August 19, 2005                [Page 7]