[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-shockey-enum-cnam) 00 01 02 03 04 05 06 07 08

           ENUM Working Group                         R. Shockey-editor
           INTERNET-DRAFT                             NeuStar
           Intended Status : Standards Track          September 22, 2008
           Expires: February 2009
    
    
           IANA Registration for an Enumservice Calling Name Delivery
              (CNAM) Information and IANA Registration for URI type
                                   'pstndata'
    
                           draft-ietf-enum-cnam-08.txt
    
    
          Status of this Memo
    
          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 becomes aware will be disclosed, in accordance with
          Section 6 of BCP 79.
    
          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 February 22, 2009.
    
          Copyright Notice
    
                Copyright (C) The IETF Trust (2008).
    
    
    
    
          R. Shockey - editor     Expires February 2009      [Page 1]
    

          Internet-Draft        CNAM Enumservice          August 2008
    
    
    
    
    
          Abstract
    
          This document registers the Enumservice 'pstndata' and
          subtype 'cnam' using the URI scheme 'pstndata:' as per the
          IANA registration process defined in the ENUM specification,
          RFC 3761 and registers a new URI type 'pstndata:'.
    
          This data is used to facilitate the transfer of Calling Name
          Delivery (CNAM) data for calls that originate on the Public
          Switched Telephone Network (PSTN) that may be displayed on
          VoIP or other Real-time Client User Agents (CUA). The
          pstndata URI is created to facilitate this transfer, however
          this URI may be used to transport other PSTN data in the
          future.
    
          Table of Contents
    
              1. Introduction ........................................ 3
              2. Protocol Design Considerations. ..................... 4
              3. Definition of PSTN CNAM Data ........................ 4
              4. The PSTNDATA URI .................................... 4
              5. Enumservice Privacy Responses and Parameters ........ 5
              6. Distribution of CNAM Data ........................... 6
              7. Enumservice CNAM Response Examples .................. 6
              8. Usage Considerations ................................ 7
              9. Privacy Considerations .............................. 7
              10. Security Considerations ............................ 8
              11. IANA Considerations ................................ 9
                11.1 IANA Enumservice Registration for "pstndata" with
                subtype "cnam"........................................ 9
                11.2 IANA Registration Template for URI "pstndata:".. 10
                11.3 Datatype Token Registry......................... 13
                11.4 IANA Registration Template for datatype Token
                "cnam"............................................... 13
              12. Normative References .............................. 14
              13. Informative References ............................ 15
              14. Acknowledgements .................................. 16
              15. Author's Address .................................. 16
              16. Full Copyright Statement .......................... 17
    
              Requirements notation
    
    
    
    
    
          R. Shockey - editor     Expires February 2009      [Page 2]
    

          Internet-Draft        CNAM Enumservice          August 2008
    
    
    
    
          The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
          "SHALLNOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
          "OPTIONAL" in this document are to be interpreted as
          described in RFC 2119 [16].
    
             1.                     Introduction
    
           RFC 3761 (ENUM) [1] is a system that transforms E.164
          numbers (The International Public Telecommunication Number
          Plan, ITU-T Recommendation E.164) [2] into domain names and
          then uses the Domain Name System (DNS), RFC 1034 [3] and
          Naming Authority Pointer Records (NAPTR) records in the
          Dynamic Delegation Discovery System (DDDS) RFC 3403 [4]) to
          query the services that are available for a specific domain
          name.
    
          This document registers an Enumservice 'cnam' according to
          the guidelines given in RFC 3761 [1], to be used for
          provisioning a NAPTR [4] resource record to indicate a type
          of functionality associated with an end point and/or
          telephone number. The registration is defined within the DDDS
          (Dynamic Delegation Discovery System
          [4][5][6][7][8]) hierarchy, for use with the "E2U" DDDS
          Application defined in RFC 3761. This document also
          registers an IANA URI type 'pstndata' per the requirements of
          RFC 4395[15].
    
          The purpose of this Enumservice is to enable service
          providers to place Calling Name Delivery information (CNAM)
          into ENUM databases or to send ENUM queries to a protocol
          converter that would have access to the Signaling System 7
          (SS7) Network.  This, in turn, could enable such parties to
          offer Calling Name Delivery services using the technology
          provided by RFC 3761 [1].
    
          The service parameters defined in RFC 3761 [1] dictate that a
          'type' and one or more 'subtype' should be specified.  Within
          this set of specifications the convention is assumed that the
          'type' (being the more generic term) defines the service and
          at least one of the 'subtype' may indicate the URI scheme.
    
          In this document, one type is specified, 'pstndata' and one
          subtype 'cnam' with the URI scheme specified, 'pstndata:'.
    
    
    
    
          R. Shockey - editor     Expires February 2009      [Page 3]
    

          Internet-Draft        CNAM Enumservice          August 2008
    
    
    
    
    
             2.                   Protocol Design Considerations.
    
          The design of this protocol was influenced by several
          factors. RFC 3761 [1] has become the defacto query-response
          protocol of choice for a variety of data types associated
          with E.164 numbering and addressing including data not
          necessarily associated with a SIP [18] or other
          communications session. RFC 3761 [1] is already being used by
          service providers to query for data that has significant
          privacy or security issues associated with it. RFC 4769 [17],
          for instance, describes an Enumservice that associates an
          E.164 number with a PSTN Local Routing Number. An Enumservice
          for CNAM data has similar design requirements of being used
          in private and closed systems.
    
          Communications service providers are concerned with the
          impact of call setup up times on the overall user experience.
          There is a strong desire to maintain a single query mechanism
          for data involving E.164 phone numbers and not complicate
          call processing applications with multiple protocol
          mechanisms. Were the query for CNAM data to require a
          secondary protocol mechanism such as LDAP or IRIS to retrieve
          the data, it could significantly impact call setup times.
    
             3.
                 Definition of PSTN CNAM Data
    
          Calling Name data is a string of up to 15 ASCII [9]
          characters of information associated with a specific calling
          party number [10] [11][12][13][14].  In the Public Switched
          Telephone Network (PSTN) this data is sent by the originating
          network only at the specific request of the terminating
          network via a SS7 Transaction Capabilities Application Part
          (TCAP) response message.
    
             4.
                  The PSTNDATA URI
    
          This document proposes a new URI scheme 'PSTNDATA:'
          specifically to carry PSTN data in general and CNAM data
          specifically.
    
              pstndatauri  = "pstndata:" datatype ["/" telephone-
             subscriber ] ";" content
    
    
    
    
          R. Shockey - editor     Expires February 2009      [Page 4]
    

          Internet-Draft        CNAM Enumservice          August 2008
    
    
    
    
             datatype     = "cnam"
                          ; Other datatypes can be defined by adding
                          ; alternative values.
             content      = [ mediatype ] [ ":base64" ] "," data
             mediatype    = [ type "/" subtype ] *( ";" parameter )
             data         = *urlchar
             parameter    = attribute "=" value
    
    
    
          ANSI standards specify the use of ASCII [9] in the response
          to TCAP queries for Calling Name data.  This specification
          does not preclude the use of internationalized characters
          within the pstn URI, nor does it preclude the use of more
          than 15 characters.
    
             5.
    Enumservice Privacy Responses and Parameters
    
          The PSTN defines several values for CNAM data in the event
          that there are privacy restrictions on the access to that
          data or that the data is unavailable.  These are defined as
          "Reason for Absence of Name" in GR-1188 [13], consequently
          the following responses to a query are reserved.
    
          Within the datatype 'cnam' two special content cases with
          mediatype parameters and data are defined:
    
          Calling Name Privacy Indicator: 'unavailable=p,<reason>'
    
          This parameter defined as the Calling Name data information
          may be available but the Calling Party does not wish to have
          their Calling Name data displayed by Called Party User
          Agents.
    
          In this case, the data element is populated with <reason>
          rather than the Calling Name itself, such as "Private".
    
          Usage: pstndata:cnam;;unavailable=p,<reason>
    
          Calling Name Status Indicator
    
          Definition: 'unavailable=u,<reason>'
    
    
    
    
    
          R. Shockey - editor     Expires February 2009      [Page 5]
    

          Internet-Draft        CNAM Enumservice          August 2008
    
    
    
    
          This parameter is defined as there is no Calling Name data
          for that E.164 number available.
    
          In this case, the data element is populated with <reason>
          rather than the Calling Name itself, such as "Unavailable" or
          "Out of Area".
    
          Usage: pstndata:cnam;;unavailable=u,<reason>
    
             6.
                   Distribution of CNAM Data
    
          The distribution of CNAM data is often highly restricted. The
          NAPTR records described herein should not be part of the
          e164.arpa DNS tree.  Distribution of this NAPTR data would be
          either within a service providers internal network, or on a
          private basis between one or more parties using a variety of
          security mechanisms to prohibit general public access.
    
          If such data was distributed in an open DNS system, a
          national regulatory body may have jurisdiction, especially
          since CNAM information may contain Personally Identifying
          Information.  Such a body may choose to restrict distribution
          of the data in such a way that it may not pass over that
          country's national borders.  How Personally Identifying
          Information is collected, distributed and subsequently
          regulated is out of the scope of this document
    
    
             7.
                   Enumservice CNAM Response Examples
    
          This section documents several examples of how this protocol
          is used for illustrative purposes only.
    
          $ORIGIN 0.0.1.0.5.5.5.3.0.7.1.e164.carrier1.example.net.
           NAPTR 10 100 "u" "E2U+pstndata:cnam"
           "!^.*$!pstndata:cnam/+15052121111;;charset=us-
          ascii,Francois%20Audet!".
    
          ORIGIN 0.0.1.0.5.5.5.3.0.7.1.e164.carrier1.example.net.
            NAPTR 10 100 "u" "E2U+pstndata:cnam"
            "!^.*$!pstndata:cnam/+15052121111;;charset=us-
             ascii,foo=bar,Francois%20Audet!".
    
    
    
    
          R. Shockey - editor     Expires February 2009      [Page 6]
    

          Internet-Draft        CNAM Enumservice          August 2008
    
    
    
    
    
          $ORIGIN 0.0.1.0.5.5.5.3.0.7.1.carrier1.example.net.
            NAPTR 10 100 "u" "E2U+pstndata:cnam"
          "!^.*$!pstndata:cnam/+15052121111;;unavailable=u,Out%20of%20A
          rea!".
    
          $ORIGIN 0.0.1.0.5.5.5.3.0.7.1.carrier1.example.net.
            NAPTR 10 100 "u" "E2U+pstndata:cnam"
            "!^.*$!pstndata:cnam;;unavailable=p,Private!".
    
          $ORIGIN 0.0.1.0.5.5.5.3.0.7.1.e164.carrier1.example.net.
            NAPTR 10 100 "u" "E2U+pstndata:cnam"
    
          "!^.*$!pstndata:cnam/+15052121111;image/gif:base64,R0lGODlhDw
            APAJEBAAAAAL+/v///AAAAACH5BAEAAAEALAAAAAAPAA8AAAIujA2Zx5EC
            4WIgWnnqvQBJLTyhE4khaG5Wqn4tp4ErFnMY+Sll9naUfGpkFL5DAQA7!".
    
             8.
                 Usage Considerations
    
          Typically, the Calling Name data in the PSTN is delivered to
          the called party during the first silent interval after the
          first ring of the phone. (see GR-1188 requirement R3-341
          [13]).  If the Called party answers the call before this,
          Calling Name data may not be delivered.
    
          This protocol could be invoked, for example, when a user
          agent within a service providers network receives an INVITE
          without a display name present.
    
          The exact mechanism or determination of when to issue an
          ENUM-CNAM request, and the formatting of SIP [18] messages is
          beyond the scope of this document.
    
             9.
                 Privacy Considerations
    
          It is assumed that carriers, service providers, or other
          organizations that originate Calling Name data will not
          publish such information in a globally visible DNS tree,
          such as e164.arpa for reasons of personal privacy protection
          unless such publication is consistent with national
          regulatory policy.
    
    
    
    
    
    
          R. Shockey - editor     Expires February 2009      [Page 7]
    

          Internet-Draft        CNAM Enumservice          August 2008
    
    
    
    
          Service providers and other organizations will probably
          privately exchange and publish this data in their internally
          cached ENUM databases, which is only able to be queried by
          trusted elements of their network, such as soft switches and
          SIP [18] proxy servers.
    
          Service providers using this query response technique are
          advised that many national jurisdictions have strict
          regulations on the use of Calling Name data and that National
          Regulatory Authorities may have special regulations that
          permit subscribers to block the use of such data before call
          setup.  Other jurisdictions have services known as anonymous
          caller rejection, meaning that calls made from a system where
          Calling Line Identification and Calling Name data are blocked
          are prevented from establishing a session.
    
    
             10.
                   Security Considerations
    
          Use of the CNAM Enumservice shall either be within a service
          providers internal network, or on a private basis between one
          or more parties using a variety of security mechanisms to
          prevent general public access.  It should be noted that this
          content type is designed to carry potentially personal
          information and as such, may be subject to restrictions
          within various national jurisdictions.
    
          In many cases, the actual information that needs to be
          protected is the combination of the Name associated with the
          Telephone Number or the association of the name with the
          telephone call.  So, it will be necessary to protect the
          response to the query that provides the association between
          the two elements.
    
          The CNAM Enumservice defined in this document is assumed to
          be used in an environment where elements are trusted and
          where attackers are not supposed to have access to the
          protocol messages between those elements.  Traffic protection
          between network elements is sometimes achieved by using IPSec
          [15] and sometimes by physically protecting the underlying
          network.  In any case, the provider should ensure that
          measures are taken to prevent both fraud and unauthorized
    
    
    
    
    
          R. Shockey - editor     Expires February 2009      [Page 8]
    

          Internet-Draft        CNAM Enumservice          August 2008
    
    
    
    
          disclosure by using a combination of authentication and
          Encryption.
    
    
             11.
                   IANA Considerations
    
          This document registers the 'cnam' Enumservice using the type
          'pstn' and the subtype 'cnam' in the Enumservice registry
          described in the IANA considerations in RFC 3761 [1].
          Details of this registration are provided in sections 13 and
          14 of this document.
    
          This document also registers with the IANA the URI
          'pstndata:' per RFC 4395 [15]
    
    
          11.1 IANA Enumservice Registration for "pstndata" with
          subtype "cnam"
    
               Enumservice Name: "cnam"
               Enumservice Type: "pstndata"
               Enumservice Subtype: "cnam"
               URI Schemes: "pstndata:"
    
                  Functional Specification:
    
          This Enumservice indicates that a resource record contains
          Calling Name Delivery Information that can be addressed by
          the associated 'pstndata:' URI scheme in order to facilitate
          the display of Calling Party information from a PSTN endpoint
          to a VoIP Client User Agent or other application.
    
               Security Considerations: See Section 9.
    
               Intended Usage: COMMON
    
               Authors:
    
          Richard Shockey and Jason Livingood, et. al. (for author
          contact detail see Authors' Addresses section)
    
    
    
    
    
    
    
          R. Shockey - editor     Expires February 2009      [Page 9]
    

          Internet-Draft        CNAM Enumservice          August 2008
    
    
    
    
    
    
          11.2 IANA Registration Template for URI "pstndata:"
    
               URI scheme name.
    
               The name of the URI is "pstndata:".
    
               Status.
    
          The intended status is Permanent.  NOTE: The distribution of
          CNAM data is often highly restricted. Usage of this URI
          should either be within a service providers internal network,
          or on a private basis between one or more parties using a
          variety of security mechanisms to prevent general public
          access. The records described herein should not be part of
          the e164.arpa or any other portion of the DNS tree.
    
          Other datatypes can be defined by adding alternative values.
          Tokens are registered with IANA.
    
          URI scheme syntax.
    
             pstndatauri  = "pstndata:" datatype ["/" telephone-
             subscriber ] ";" content
             datatype     = "cnam"
                          ; Other datatypes can be defined by adding
                          ; alternative values.
             content      = [ mediatype ] [ ":base64" ] "," data
             mediatype    = [ type "/" subtype ] *( ";" parameter )
             data         = *urlchar
             parameter    = attribute "=" value
    
             where "telephone-subscriber" is imported from RFC 3966
             [19], "urlchar" is imported from RFC 2396 [20], and
             "attribute" and "value" are imported from RFC 2045 [21].
    
               URI scheme semantics.
    
          The PSTN defines several values for CNAM data in the event
          that there are privacy restrictions on the access to that
          data or that the data is unavailable.  These are defined as
    
    
    
    
    
          R. Shockey - editor     Expires February 2009      [Page 10]
    

          Internet-Draft        CNAM Enumservice          August 2008
    
    
    
    
          "Reason for Absence of Name" in GR-1188 [13], consequently
          the following responses to a query are reserved.
    
          Within the datatype 'cnam' two special content cases with
          mediatype parameters and data are defined:
    
          Calling Name Privacy Indicator: 'unavailable=p,<reason>'
    
          This parameter defined as the Calling Name data information
          may be available but the Calling Party does not wish to have
          their Calling Name data displayed by Called Party User
          Agents.
    
          In this case, the data element is populated with <reason>
          rather than the Calling Name itself, such as "Private".
    
          Usage: pstndata:cnam;;unavailable=p,<reason>
    
          Calling Name Status Indicator
    
          Definition: 'unavailable=u,<reason>'
    
          This parameter is defined as there is no Calling Name data
          for that E.164 number available.
    
          In this case, the data element is populated with <reason>
          rather than the Calling Name itself, such as "Unavailable" or
          "Out of Area".
    
          Usage: pstndata:cnam;;unavailable=u,<reason>
    
          Encoding considerations.
    
          The purpose of this URI is to enable service providers to
          place   Calling Name Delivery information (CNAM) into RFC
          3761 [1] databases or to send ENUM queries to a protocol
          converter that would have access to the Signaling System 7
          (SS7) Network.  This, in turn, could enable such parties to
          offer Calling Name Delivery services using the technology
          provided by RFC 3761[1].
    
          The information stored in these databases can be encoded to
          facilitate storage and retrieval operations.  The type of
    
    
    
    
          R. Shockey - editor     Expires February 2009      [Page 11]
    

          Internet-Draft        CNAM Enumservice          August 2008
    
    
    
    
          encoding used is identified using appropriate media type
          parameters.  If not otherwise identified, character data is
          presumed to be encoded using US-ASCII.
    
          Applications and/or protocols that use this URI scheme name.
    
          This URI scheme is intended for use in ENUM RFC 3761 [1]
          databases.
    
          Interoperability considerations.
    
          The URI is designed to be used specifically in conjunction
          with trusted systems that utilize the RFC 3761 [1] databases.
    
          Security considerations:
    
          The distribution of CNAM data is often highly restricted.
          Distribution of this data would typically be either within a
          service providers internal network, or on a private basis
          between one or more parties using a variety of security
          mechanisms to prohibit general public access.  It should be
          noted that this content type is designed to carry potentially
          personal information and as such, may be subject to
          restrictions within various national jurisdictions. In
          many cases, the actual information that needs to be protected
          is the combination of the Name associated with the Telephone
          Number or the association of the name with the telephone
          call.  So, it will be necessary to protect the response to
          the query that provides the association between the two
          elements.
    
          The pstn URI defined in this document is assumed to be used
          in an environment where elements are trusted and where
          attackers are not supposed to have access to the protocol
          messages between those elements.  Traffic protection between
          network elements is sometimes achieved by using IPSec [15]
          and sometimes by physically protecting the underlying
          network. In any case, the provider should ensure that
          measures are taken to prevent both fraud and unauthorized
          disclosure by using a combination of authentication and
          Encryption.
    
    
    
    
    
    
          R. Shockey - editor     Expires February 2009      [Page 12]
    

          Internet-Draft        CNAM Enumservice          August 2008
    
    
    
    
    
          11.3 Datatype Token Registry
    
          IANA is requested to create a registry for datatype tokens
          described in section 11.2.  Values shall be registered using
          the Standards Action policy described in BCP 26 [22].
    
          Specifications presented to the IESG for standards action
          MUST include both the requested token and a syntax
          specification for the token.
    
          Registry Name: "pstndata: URI datatype Token Registry"
    
          Registration Template:
    
          Datatype name: <token name>
    
          Datatype specification: <name of IESG-approved standard>
    
    
          11.4 IANA Registration Template for datatype Token "cnam"
    
          Datatype name: cnam
    
          Datatype specification: Section 11.2 of this document.
    
               Contacts.
    
                 Richard Shockey
                 NeuStar
                 46000 Center Oak Plaza
                 Sterling, VA 20166
                 USA
    
                 Phone: +1-571-434-5651
                 Email: richard.shockey@neustar.biz
    
    
                 Jason Livingood
                 Comcast Cable Communications
                 1500 Market Street
                 Philadelphia, PA 19102
                 USA
    
    
    
    
          R. Shockey - editor     Expires February 2009      [Page 13]
    

          Internet-Draft        CNAM Enumservice          August 2008
    
    
    
    
    
                 Phone: +1-215-981-7813
                 Email: jason_livingood@cable.comcast.com
    
    
          Author/Change controller.
    
          This specification is a work item of the IETF ENUM working
          group, with the mailing list address enum@ietf.org
    
                   References.
    
          [ENUM] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
          Resource Identifiers (URI) Dynamic Delegation Discovery
          System (DDDS) Application (ENUM)", RFC 3761, April 2004.
    
    
             12.
                  Normative References
    
             [1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
             Resource  Identifiers (URI) Dynamic Delegation Discovery
             System (DDDS) Application (ENUM)", RFC 3761, April 2004.
    
             [2] ITU-T, "The International Public Telecommunication
             Number Plan", Recommendation E.164, May 1997.
    
             [3] Mockapetris, P., "Domain Names - Concepts and
             Facilities", RFC 1034, November 1987.
    
             [4] Mealling, M., "Dynamic Delegation Discovery System
             (DDDS) Part Three: The Domain Name System (DNS) Database",
             RFC 3403, October2002.
    
             [5] Mealling, M., "Dynamic Delegation Discovery System
             (DDDS)  Part One: The Comprehensive DDDS", RFC 3401,
             October 2002.
    
             [6] Mealling, M., "Dynamic Delegation Discovery System
             (DDDS) Part   Two: The Algorithm", RFC 3402, October 2002.
    
             [7] Mealling, M., "Dynamic Delegation Discovery System
             (DDDS) Part Four: The Uniform Resource Identifiers (URI)",
             RFC 3404, October 2002.
    
    
    
    
          R. Shockey - editor     Expires February 2009      [Page 14]
    

          Internet-Draft        CNAM Enumservice          August 2008
    
    
    
    
    
             [8] Mealling, M., "Dynamic Delegation Discovery System
             (DDDS) Part Five: URI.ARPA Assignment Procedures", RFC
             3405, October 2002.
    
             [15] Hansen, T, et al., "The "Guidelines and Registration
             Procedures for New URI Schemes", RFC 4395, February 2006
    
             [16] Bradner, S., "Key words for use in RFC's to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.
    
             [17] Livingood, J. and Shockey, R. "IANA Registration for
             an
             Enumservice Containing Public Switched Telephone Network
             (PSTN) Signaling Information", RFC 4769, November 2006
    
             [18] Rosenberg, J., et al., "SIP: Session Initiation
             Protocol", RFC 3261, June 2002.
    
             [19] Schulzrinne, H., "The tel URI for Telephone Numbers",
             RFC 3966, December 2004.
    
             [20] Berners-Lee, T., et al., "Uniform Resource
             Identifiers (URI): Generic Syntax", RFC 3986, January
             2005.
    
             [21] Freed, N. and Borenstein, N.S. "Multipurpose Internet
             Mail Extensions (MIME) Part One: Format of Internet
             Message Bodies",   RFC 2045, November 1996.
    
             [22] Narten, T. and Alvestrand, H. "Guidelines for Writing
             an IANA Considerations Section in RFCs", BCP 26, October
             1998
    
    
             13.
                  Informative References
    
             [9] American National Standards Institute (ANSI), Coded
             Character Set - 7-Bit American National Standard Code for
             Information Interchange, ANSI X3.4, 1986.
    
             [10] American National Standards Institute (ANSI),
             Telecommunications Network-to-Customer Installation
    
    
    
    
          R. Shockey - editor     Expires February 2009      [Page 15]
    

          Internet-Draft        CNAM Enumservice          August 2008
    
    
    
    
             Interfaces - Analog Voice grade  Switched Access Lines
             with Calling Number Delivery, Calling Name Delivery, or
             Visual Message-Waiting Indicator Features, ANSI
             T1.6401.03-1998
    
             [11] American National Standards Institute (ANSI),
             Telecommunications- Integrated Services Digital Network
             (ISDN) - Calling Line Identification Presentation and
             Restriction Supplementary Services, ANSI T1.625-1993
    
             [12] American National Standards Institute ANSI),
             Telecommunications - Calling Name Identification
             Presentation, ANSI T1.641-1995
    
             [13] Telcordia Technologies, "CLASS Feature: Calling Name
             Delivery Generic Requirements", GR-1188-CORE, Issue 2,
             December 2000
    
             [14] Telcordia Technologies, "CLASS Feature: Calling
             Number Delivery", GR-31-CORE, Issue 1, June 2000
    
             [15] Kent, S. et al, "Security Architecture for the
             Internet Protocol", RFC 4301, December 2005
    
             14.
                 Acknowledgements
    
          The authors wish to thank Larry Masinter, Paul Kyzivat,
          Hadriel Kaplan and Don Troshynski for invaluable input to
          this document.
    
             15.
                  Author's Address
    
    
               Richard Shockey - editor
               NeuStar
               46000 Center Oak Plaza
               Sterling, VA 20166
               USA
               Phone: +1-571-434-5651
               Email: richard.shockey@neustar.biz
    
               Jason Livingood
               Comcast Cable Communications
    
    
    
    
          R. Shockey - editor     Expires February 2009      [Page 16]
    

          Internet-Draft        CNAM Enumservice          August 2008
    
    
    
    
               1500 Market Street
               Philadelphia, PA 19102
               USA
               Phone: +1-215-981-7813
               Email: jason_livingood@cable.comcast.com
    
               Kevin McCandless
               Verisign
               7400 West 129th Street
               Overland Park, KS 66213
               USA
               Phone : +1 913-814-6397
               Email : KMcCandless@verisign.com
    
               Manjul Maharishi
               Verisign
               21345 Ridgetop Circle
               Dulles  VA  20166
               Phone :+1 703-948-3255
               Email : mmaharishi@verisign.com
    
               Scott Hollenbeck
               Verisign
               21345 Ridgetop Circle
               Dulles  VA  20166
               Phone : +1 703-948-3257
               Email : shollenbeck@verisign.com
    
    
             16.
                  Full Copyright Statement
    
                Copyright (C) The IETF Trust (2008).
    
          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.
    
          This document and the information contained herein are
          provided on an "AS IS" basis and THE CONTRIBUTOR, THE
          ORGANIZATION HE/SHE PRESENTS OR IS SPONSORED BY (IF ANY), THE
          INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING
          TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
          INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
    
    
    
    
          R. Shockey - editor     Expires February 2009      [Page 17]
    

          Internet-Draft        CNAM Enumservice          August 2008
    
    
    
    
          INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
          IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
          PARTICULAR PURPOSE.
    
          Intellectual Property
    
          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.
    
          Acknowledgment
    
          Funding for the RFC Editor function is provided by the IETF
          Administrative Support Activity (IASA).
    
    
    
    
    
    
    
    
    
    
    
    
          R. Shockey - editor     Expires February 2009      [Page 18]
    

Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/