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

Versions: (draft-ietf-enum-void) 00 01 02 03 04

ENUM                                                          R. Stastny
Internet-Draft                                                     Oefeg
Intended status: Standards Track                               L. Conroy
Expires: September 30, 2008                                         RMRL
                                                                 J. Reid
                                                                DNS-MODA
                                                          March 29, 2008


                IANA Registration for Enumservice UNUSED
                    <draft-ietf-enum-unused-04.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 September 30, 2008.















Stastny, et al.        Expires September 30, 2008               [Page 1]


Internet-Draft    IANA Registration Enumservice UNUSED        March 2008


Abstract

   This document registers the Enumservice "unused" using the URI scheme
   "http:" as per the IANA registration process defined in the ENUM
   specification, RFC 3761.  This Enumservice may be used to indicate
   that the E.164 number (or E.164 number range) tied to the domain in
   which the enclosing NAPTR is published is not allocated or assigned
   for communications service.  When such an indication is provided, an
   ENUM client can detect calls that will fail "early".


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Background: ENUM Lookup Cases  . . . . . . . . . . . . . . . .  5
     3.1.  ENUM Registration Cases  . . . . . . . . . . . . . . . . .  5
     3.2.  ENUM Outcomes  . . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  "Default" Strategy on receiving response with RCODE=3  . .  6
     3.4.  The Problem  . . . . . . . . . . . . . . . . . . . . . . .  7
     3.5.  "ENUM only" query loop . . . . . . . . . . . . . . . . . .  7
   4.  The Proposed Solution  . . . . . . . . . . . . . . . . . . . .  8
   5.  ENUM Service Registration - UNUSED . . . . . . . . . . . . . .  9
   6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     10.2. Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16



















Stastny, et al.        Expires September 30, 2008               [Page 2]


Internet-Draft    IANA Registration Enumservice UNUSED        March 2008


1.  Introduction

   The Circuit Switched Network (CSN) of which the Public Switched
   Telephone Network (PSTN), Integrated Services Digital Network (ISDN),
   and Public Land Mobile Network (PLMN) are part is designed to use
   E.164 numbers [E164] as native global addresses.  If a potential
   caller has an E.164 number, then to place a call using this address
   he or she needs a way to pass the request either directly or
   indirectly to systems "in" the CSN for them to forward.

   ENUM ("E.164 Number Mapping") has introduced a mechanism to find
   other contact addresses when given an E.164 number.  Thus, if the
   caller (or an agent somewhere in the call path) has access to the
   global Domain Name System (DNS), they can use ENUM as described in
   RFC 3761 [RFC3761] to find alternative contacts to the E.164 number
   and place the call using whatever system was indicated in those
   contacts.  In its intended use, an ENUM query would return a set of
   NAPTR ("Naming Authority Pointer") resource records [RFC3403], and
   these would be processed to select the appropriate communications
   contact choices.  Each communications contact is held in a URI
   ("Universal Resource Indicator") generated from the contents of a
   NAPTR.

   However, ENUM entries may not exist for a given E.164 number for two
   reasons.  Either the assignee who is entitled to register an ENUM
   domain associated with the E.164 number they hold has chosen not to
   request this registration, or the number is not currently allocated
   or assigned for communications service.

   In either situation, the caller has no other information and so no
   alternative to placing the call via the system that uses E.164
   numbers as global identifiers; at present, this is the CSN.



















Stastny, et al.        Expires September 30, 2008               [Page 3]


Internet-Draft    IANA Registration Enumservice UNUSED        March 2008


2.  Terminology

   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 RFC 2119 [RFC2119].














































Stastny, et al.        Expires September 30, 2008               [Page 4]


Internet-Draft    IANA Registration Enumservice UNUSED        March 2008


3.  Background: ENUM Lookup Cases

   This section describes the problems that arise where the ENUM system
   does not hold full information on all telephone numbers and clients
   display typical behaviour.  The proposed solution to the problems
   described here is covered in Section 4 and in the unused Enumservice
   registration in Section 5.

3.1.  ENUM Registration Cases

   Traditionally, communications service is provided via a network that
   uses telephone numbers as global addresses.  Examples of such
   networks are the PSTN, ISDN and PLMN.

   ENUM registrations are normally allowed only to customers who receive
   communications service via a telephone number.  There may or may not
   be an ENUM registration when such service is provided.  An ENUM
   registration is usually not permitted when no customer receives
   service via the corresponding telephone number.

   When considering ENUM registrations associated with telephone
   numbers, there are six scenarios:

   1.  The number is not allocated to a service provider,

   2.  the number is not currently used by that provider for
       communications service for a customer,

   3.  the number is used to provide communications service to a
       customer and either that customer has not chosen to maintain an
       ENUM registration associated with that number, or the National
       Regulatory Authority (NRA) responsible for these numbers does not
       allow ENUM registrations,

   4.  the number is used to provide communications service to a
       customer and that customer has an ENUM registration associated
       with that number.

   Communications service may alternatively be provided only by recourse
   to an ENUM lookup.  Such numbers are known as "ENUM only" ranges.

   For these numbers there are two further possibilities:

   5. There is an ENUM registration and that number may be used for
      communications service,






Stastny, et al.        Expires September 30, 2008               [Page 5]


Internet-Draft    IANA Registration Enumservice UNUSED        March 2008


   6. there is no ENUM registration and therefore the number is not used
      for communications service.

3.2.  ENUM Outcomes

   Assuming properly configured name servers and protocol conformant
   software, an ENUM query on a domain associated with a telephone
   number may elicit one of several outcomes based on the DNS [RFC1034]
   response.

   In uses cases 1,2,3,and 6, the DNS response will indicate Name Error
   (RCODE=3, commonly known as NXDOMAIN, signifying that the domain name
   referenced in the query does not exist).

   In use cases 4 and 5, the DNS response will indicate No Error
   (RCODE=0).  There are three possibilities here:

   o  There may be at least one usable NAPTR (meaning one in which the
      Enumservice is supported and the URI is resolved), in which case a
      communications attempt can be made.

   o  Even though the DNS response indicates no error, there may not be
      any usable NAPTRs in that response.  This may happen because the
      domain owner has chosen not to populate the zone with NAPTR
      records.  This response (RCODE=0, Number of Answers=0) is also
      known as NOHOST, meaning that the queried name exists but not for
      the record type that was requested.

   o  However, even if there are NAPTRs returned, none of the ones
      present may be usable.  For example, the NAPTR RRSet may include
      only an "h323" Enumservice, whilst the client node is capable only
      of processing "sip" or "voice:tel" Enumservices.

   As it cannot know the case it has encountered, if the client receives
   a DNS response with no usable NAPTRs or one with RCODE=3, it must
   decide whether or not to attempt to place the call using other means.

3.3.  "Default" Strategy on receiving response with RCODE=3

   Not every customer has an ENUM registration if provided service via a
   network that uses telephone numbers natively, and until this is the
   case, a reasonable strategy has been to attempt to place the call via
   such a network if it receives an ENUM response with RCODE=3.  This is
   especially true if the National Regulatory Authority has chosen not
   to permit ENUM registrations at all for the telephone numbers under
   its control.

   This may also be the chosen strategy if the client receives a



Stastny, et al.        Expires September 30, 2008               [Page 6]


Internet-Draft    IANA Registration Enumservice UNUSED        March 2008


   response with RCODE=0 (No Error), but with no usable NAPTRs.

3.4.  The Problem

   In the case of an ENUM client getting a DNS response with RCODE=3,
   the semantics of that reply are ambiguous.  Is this case 1,2,3, or 6?
   It is useful for the client to know if this is case 3, as in this
   case the "default" strategy will succeed.  In cases 1 and 2, trying
   to place the call via a network that uses such numbers natively will
   result in that network returning an error.  However, in case 6 even
   this cannot be guaranteed.

   Similarly, if the client finds no usable NAPTRs, is this case 4 or
   case 5?  In the latter case the strategy will fail, whilst in the
   former case it will succeed.

3.5.  "ENUM only" query loop

   However, for the "ENUM only" cases, there is a further problem.  If
   the call is placed via a network that uses such numbers natively, it
   can be processed only via an ENUM lookup, and typically this will
   involve a gateway from that network performing the lookup and
   delivering the call onwards based on the response.  If that gateway
   receives a response with RCODE=3 or one including no usable NAPTRs,
   then employing the "default" strategy (attempting the call via a
   network that uses these numbers natively) will cause a "loop".  The
   call will be redirected to this network, where it will be routed to a
   gateway, this gateway will perform a lookup, will receive the same
   response, will attempt to place the call back to that network, and so
   on.





















Stastny, et al.        Expires September 30, 2008               [Page 7]


Internet-Draft    IANA Registration Enumservice UNUSED        March 2008


4.  The Proposed Solution

   We propose an explicit indication of this "number unused" state (as
   described in points 1,2, and 6 in Section 3.1).  This uses a NAPTR in
   the zone associated with an unused telephone number, with an
   Enumservice called "unused" that should be taken as an assertion that
   the associated E.164 number is not assigned to a subscriber for
   communications service; it's an unused number.

   This NAPTR can also be used by a National Regulatory Authority (NRA)
   to indicate number blocks that it has reserved, and has not allocated
   to a service provider.

   It is a matter for individual countries whether or not they will
   support (or require) information giving the identity of the current
   "owner" of an E.164 number within their responsibility to be made
   available via IRIS/WHOIS.  Thus it may not be possible to use these
   protocols to find out the entity responsible for a number or number
   range concerned, particularly where that number or range is not
   currently "in use".

   Since the registration and syntax of a terminal NAPTR for "E2U"
   Enumservices requires at least one URI scheme to be defined, we
   propose that the Enumservice "unused" will use an "http:" URI.  The
   content referenced in this "http:" URI is a national matter.  For
   example, it may be used to refer to a resource providing additional
   information about the reason for the existence of this record, and/or
   (where required by the competent regulatory authority) the identity
   of the entity responsible for this number.






















Stastny, et al.        Expires September 30, 2008               [Page 8]


Internet-Draft    IANA Registration Enumservice UNUSED        March 2008


5.  ENUM Service Registration - UNUSED

   Enumservice Name: "unused"

   Enumservice Type: "unused"

   Enumservice Subtypes: "data"

   URI Schemes: "http:"

   Functional Specification: The proposed solution in Section 4.

   Definition of expected action:

      When an ENUM lookup for a number explicitly returns the "unused"
      NAPTR, the response indicates to the client that the number is
      known to ENUM but there are no implicit communication end-points
      associated with it.  The client can then signal an error to the
      application or end user instead of then trying and failing to
      terminate the call on the PSTN, which would have been the typical
      behaviour of an ENUM-aware VoIP/PSTN gateway if the ENUM lookup
      had returned a DNS response indicating NXDOMAIN or NOHOST.

      Thus, if a NAPTR with this Enumservice is received and processed,
      it indicates that there are no possible communication methods that
      can be used to reach the end point.  The queried E.164 number is
      currently not allocated, or unassigned to a subscriber for
      communications service.

      The recipient SHOULD treat this response as if they had received a
      "number not in service" indication from a terminating network.

      Note that the generated URI is not a potential target for any
      current call.  The content referred to in the "http:" URI
      [RFC2616] MUST NOT be used in normal call processing but only if
      there is a non-call related reason.

   Security considerations: see Section 7.

   Intended usage: COMMON

   Authors

      Lawrence Conroy, Richard Stastny, Jim Reid (for authors contact
      details see Authors' Addresses section).

   Any other information that the author deems interesting: None




Stastny, et al.        Expires September 30, 2008               [Page 9]


Internet-Draft    IANA Registration Enumservice UNUSED        March 2008


6.  Examples

   1.  Unassigned number

       $ORIGIN 0.6.9.2.3.6.1.4.4.e164.arpa.
       3.8.0 NAPTR 10 100 "u" "E2U+unused:http"
           "!^.*$!http://www.nra.example/static/numbering/
       cupid.htm?cupid=001!" .

       This indicates that the controller of the number block +441632960
       does not provide telephony service via the number +441632960083;
       it is not assigned to a subscriber.

   2.  Unallocated number

       $ORIGIN 0.6.9.4.5.1.1.4.4.e164.arpa.
       * NAPTR 10 100 "u" "E2U+unused:http"
           "!^.*$!http://www.nra.example/static/numbering/
       sabc.htm?SABC=1154!"

       This indicates that the number block +441154960 is not allocated
       by the NRA to any service provider and therefore no number in
       this block provides any communication service.




























Stastny, et al.        Expires September 30, 2008              [Page 10]


Internet-Draft    IANA Registration Enumservice UNUSED        March 2008


7.  Security Considerations

   DNS does not make policy decisions about the records that it shares
   with an inquirer.  All DNS records must be assumed to be available to
   all inquirers at all times.  The information provided within an ENUM
   record set must therefore be considered to be open to the public.

   An analysis of threats specific to the dependence of ENUM on the DNS,
   and the applicability of DNSSEC ("Domain Name Security") [RFC4035] to
   these, is provided in [RFC3833].









































Stastny, et al.        Expires September 30, 2008              [Page 11]


Internet-Draft    IANA Registration Enumservice UNUSED        March 2008


8.  IANA Considerations

   This document requests registration of the "unused" Enumservice with
   the sub-type "unused:http" according to the guidelines and
   specifications in RFC 3761 [RFC3761] and the definitions in this
   document.  This Enumservice is intended for use with the "http:" URI
   scheme.












































Stastny, et al.        Expires September 30, 2008              [Page 12]


Internet-Draft    IANA Registration Enumservice UNUSED        March 2008


9.  Acknowledgements

   Thanks to Patrik Faltstrom, Michael Mealling and Peter Koch for their
   thorough feedback, and colleagues in ETSI TISPAN who helped to
   clarify the operational features during the development of
   [ETSI-TS102172].  Thanks also to the members of the ENUM working
   group for their wide ranging discussions.  These have helped to
   indicate where changes were needed in this document to help explain
   what is an intrinsically difficult subject.  Finally, thanks to Alex
   Mayrhofer for his useful document review, picking up the remaining
   issues.








































Stastny, et al.        Expires September 30, 2008              [Page 13]


Internet-Draft    IANA Registration Enumservice UNUSED        March 2008


10.  References

10.1.  Normative References

   [E164]     ITU-T, "The International Public Telecommunication Number
              Plan", Recommendation E.164, February 2005.

   [RFC1034]  Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
              RFC 1034, November 1987.

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

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC3403]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part Three: The Domain Name System (DNS) Database",
              RFC 3403, October 2002.

   [RFC3761]  Faltstrom, P. and M. Mealling, "The E.164 to Uniform
              Resource Identifiers (URI) Dynamic Delegation Discovery
              System (DDDS) Application (ENUM)", RFC 3761, April 2004.

10.2.  Informative References

   [ETSI-TS102172]
              ETSI, "Minimum Requirements for Interoperability of ENUM
              Implementations", ETSI TS 102 172, January 2005.

   [RFC3833]  Atkins, D. and R. Austein, "Threat Analysis of the Domain
              Name System (DNS)", RFC 3833, August 2004.

   [RFC4035]  Arends, R. and et al. , "Protocol Modifications for the
              DNS Security Extensions", RFC 4035, March 2005.















Stastny, et al.        Expires September 30, 2008              [Page 14]


Internet-Draft    IANA Registration Enumservice UNUSED        March 2008


Authors' Addresses

   Richard Stastny
   Oefeg
   Postbox 147
   1103 Vienna
   Austria

   Phone: +43-664-420-4100
   Email: Richard.stastny@oefeg.at


   Lawrence Conroy
   Siemens Roke Manor Research
   Roke Manor
   Romsey
   United Kingdom

   Phone: +44-1794-833666
   Email: lwc@roke.co.uk


   Jim Reid
   DNS-MODA
   6 Langside Court
   Bothwell, SCOTLAND
   United Kingdom

   Phone: +44 1698 852881
   Email: jim@dns-moda.org





















Stastny, et al.        Expires September 30, 2008              [Page 15]


Internet-Draft    IANA Registration Enumservice UNUSED        March 2008


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











Stastny, et al.        Expires September 30, 2008              [Page 16]


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