Uniform Resource Name (URN) Namespace for the National Emergency Number Association (NENA)
draft-rosen-urn-nena-03

Network Working Group                                           B. Rosen
Internet-Draft                                                   NeuStar
Intended status: Informational                          October 12, 2010
Expires: April 15, 2011

 Universal Resource Name (URN) Namespace for National Emergency Number
                           Association (NENA)
                        draft-rosen-urn-nena-03

Abstract

   This document describes the Namespace Identifier (NID) 'nena' for
   Uniform Resource Names (URN) resources published by National
   Emergency Number Association (NENA).  NENA defines and manages
   resources that utilize this URN model.  Management activities for
   these and other resource types are provided by the NENA Registry
   System (NRS).

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on April 15, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of

Rosen                    Expires April 15, 2011                 [Page 1]
Internet-Draft             URN nena Namespace               October 2010

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  URN Specification for "nena" NID  . . . . . . . . . . . . . . . 3
   3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   4.  Namespace Considerations  . . . . . . . . . . . . . . . . . . . 5
   5.  Community Considerations  . . . . . . . . . . . . . . . . . . . 6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7

Rosen                    Expires April 15, 2011                 [Page 2]
Internet-Draft             URN nena Namespace               October 2010

1.  Introduction

   The National Emergency Number Association (NENA) is currently in the
   process of setting standards, processes and procedures for the use of
   an IP-based Emergency Services IP Network (ESInet) for all public
   safety entities in North America.  Some of the solutions being
   developed by NENA require XML namespaces that are managed so that
   they are unique and persistent.  To assure that the uniqueness is
   absolute, the registration of a specific Uniform Resource Name (URN)
   [RFC2141] Namespace ID (NID) for use by NENA is required.  This
   document defines and registers such a namespace.

2.  URN Specification for "nena" NID

  Namespace ID: nena

  Registration Information:
    registration version number: 1
    registration date: YYYY-MM-DD  [RFC Editor, please replace with the
            date of approval of this document for publication as an RFC]

  Declared registrant of the namespace:
    Registering organization
      Name:       National Emergency Number Association (NENA)
      Address:    4350 North Fairfax Drive, Suite 750
                  Arlington, VA 22203-1695

  Designated contact:
    Role:    NENA Registry Services Administrator
    Email:   nrs-admin@nena.org

  Declaration of syntactic structure:
  The Namespace Specific String (NSS) of all URNs that use the "nena"
  NID will have the following structure:
      {NENAclass}:{ClassSpecificString}

   The "NENAclass" conforms to the URN syntax requirements [RFC2141] and
   defines a specific class of resource type.  Each class will have a
   specific labeling scheme that is covered by "ClassSpecificString",
   which also conforms to the naming requirements of [RFC2141].

   NENA maintains a naming authority, the National Emergency Number
   Association (NENA) Registration System (NRS) that will manage the
   assignment of "NENAclass" and the specific registration values
   assigned for each class.  Other NENA Standards documents will define
   the "ClassSpecificStrings" for a given "NENAclass".

Rosen                    Expires April 15, 2011                 [Page 3]
Internet-Draft             URN nena Namespace               October 2010

   Relevant ancillary documentation:
   The National Emergency Number Association Registration System (NRS)
   provides information on the registered resources and the
   registrations for each.  More information about NRS and the
   registration activities and procedures to be followed are defined in
   "NENA Registry System Standard", NENA 70-001 [NENA70-001], which is
   available at: http://www.nena.org/standard/nena-registry-system.

   Identifier uniqueness considerations:
   The NRS will manage resources using the "nena" NID and will be the
   authority for managing the resources and subsequent strings
   associated.  The NRS shall ensure the uniqueness of all nena URNs by
   checking such names against the list of existing namespace names, as
   documented in NENA 70-001 [NENA70-001].

   Identifier persistence considerations:
   NRS will provide clear documentation of the registered uses of the
   "nena" NID.  NRS will establish a registry for NENAclass as defined
   in NENA08-003 [NENA08-003].  Each NENAclass will have a separate
   description in the registry and may have its own sub-registry.  In
   particular new NENAclass registry entries will require a full NENA
   technical standard document.

   NRS will maintain a website at a stable address which provides XML
   and text renderings of the urn:nena registry.

   Process of identifier assignment:
   The NRS processes and procedures for identifier assignment is
   documented in NENA 07-001 [NENA70-001].  The registry that will
   control the urn:nena namespace is defined in NENA 08-003
   [NENA08-003].  In particular, assignments to the NENAclass registry
   will require a NENA Technical Standard document.  Subregistries for
   particular NENAclasses may be established by such technical
   standards.  Subregistries may be defined to have more liberal
   management policies as defined in NENA 70-001 [NENA70-001], but must
   be NRS managed and will not be permitted to be delegated to any other
   organization or registry.  Thus NRS will manage the entire urn:nena
   tree.

   Process for identifier resolution:
   The namespace is not currently listed with a Resolution Discovery
   System (RDS), but nothing about the namespace prohibits the future
   definition of appropriate resolution methods or listing with an RDS.

   Rules for Lexical Equivalence:
   No special considerations; the rules for lexical equivalence of
   [RFC2141] apply.

Rosen                    Expires April 15, 2011                 [Page 4]
Internet-Draft             URN nena Namespace               October 2010

   Conformance with URN Syntax:
   No special considerations.

   Validation mechanism:
   None specified.  URN assignment will be handled by procedures
   implemented in support of NENA activities.

   Scope:
   Global

3.  Examples

   The following examples are representative URNs that could be assigned
   by NRS.  They may not be the actual strings that would be assigned.

   NENAresource "psaproute"
   Syntax: "urn:nena:emergencyresponders:<responder name>"
   ResourceSpecificString: simple string with name of responder,
                           defined in a sub-registry
   Use: Defines the URN to be used for queries to an NG9-1-1 Emergency
   Call Routing Function that provides URIs for responding agencies.

   Examples:
   urn:nena:emergencyresponders:ambulance
   urn:nena:emergencyresponders:fire
   urn:nena:emergencyresponders:police
   urn:nena:emergencyresponders:poison
   urn:nena:emergencyresponders:coastguard
   urn:nena:emergencyresponders:marine

4.  Namespace Considerations

   The National Emergency Number Association has developed standards for
   emergency calling in North America for several decades.  NENA is
   developing a variety of applications and services using Internet
   protocols built upon on IETF standards.  Some of these services
   require that supporting information (e.g., data descriptions,
   attributes, etc.) be fully specified.  For proper operation,
   descriptions of the needed supporting information must exist and be
   available in a unique, reliable, and persistent manner.  These
   dependencies provide the basis of need for namespaces, in one form or
   another and will enable NENA to define URNs that are to assign
   cleaner, more general, more permanent, more reliable, and more
   controllable namespace names related to NENA standards, while keeping
   urns defined by NENA properly separate from the IETF defined URNs.

Rosen                    Expires April 15, 2011                 [Page 5]
Internet-Draft             URN nena Namespace               October 2010

   As the National Emergency Number Association work is ongoing and
   covers many technical areas, the possibility of binding to various
   other namespace repositories has been deemed impractical.  Each
   object or description, as defined in NENA, could possibly be related
   to multiple different other namespaces, so further conflicts of
   association could occur.  Thus the intent is to utilize the National
   Emergency Number Association Registration System, operated by NENA,
   as the naming authority for NENA-defined objects and descriptions.

5.  Community Considerations

   The North American public safety organizations will benefit from
   publication of this namespace by having permanent and reliable URNs
   to be used with protocols defined by NENA.  The objects and
   descriptions required for services defined by NENA are generally
   available for use by other organizations.  The National Emergency
   Number Association will provide access and support for name requests
   by these organizations within the constraints of the defined NRS
   processes and the specific urn:nena registry and subregistries.  This
   support can be enabled in a timely and responsive fashion as new
   objects and descriptions are produced.  These will be enabled in a
   fashion similar to current IANA processes as documented in NENA70-001
   [NENA70-001].

   NRS establishes registries when called for in a NENA Technical
   Standard.  Such standards must provide NRS with clear and concise
   instructions on creating and maintaining such registries.  Defined
   management policies include "NENA Technical Standard Required", "NENA
   Document Required", "Expert Review" and "First Come First Served",
   which correspond to similar IANA management policies.  NENA is
   establishing a website which provides controlled entry of new
   registries and entries in registries, and automatically produces html
   and xml descriptions of registry contents that are used by vendors
   and other consumers of the content.

6.  Security Considerations

   There are no additional security considerations other than those
   normally associated with the use and resolution of URNs in general.

7.  IANA Considerations

   This document adds a new entry in the urn-namespaces registry.  The
   namespace should be "nena".  The defining document is this RFC.  The
   entry can be found at: http://www.iana.org/assignments/urn-namespaces

Rosen                    Expires April 15, 2011                 [Page 6]
Internet-Draft             URN nena Namespace               October 2010

   and any associated mirrors.

8.  Acknowledgements

   The author thanks Alfred Hoenes (TR-Sys) for his careful reading and
   extensive comments and suggestions.  The author also acknowledges
   that the text from [RFC4358] formed the basis of this document.

9.  References

9.1.  Normative References

   [RFC2141]  Moats, R., "URN Syntax", RFC 2141, May 1997.

9.2.  Informative References

   [NENA08-003]
              NENA, "Detailed Functional and Interface Specification for
              the NENA i3 Solution - Stage 3", NENA Standard 08-003,
              September 2010.

   [NENA70-001]
              NENA, "NENA Registry System Standard", NENA Standard 70-
              001, September 2009.

   [RFC3406]  Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
              "Uniform Resource Names (URN) Namespace Definition
              Mechanisms", BCP 66, RFC 3406, October 2002.

   [RFC4358]  Smith, D., "A Uniform Resource Name (URN) Namespace for
              the Open Mobile Alliance (OMA)", RFC 4358, January 2006.

Author's Address

   Brian Rosen
   NeuStar, Inc.
   470 Conrad Dr
   Mars, PA  16046
   US

   Email: br@brianrosen.net

Rosen                    Expires April 15, 2011                 [Page 7]