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

Versions: (RFC 3761) 00 01 02 03 04 05 06 07 08 09 RFC 6116

ENUM                                                       Scott Bradner
Internet-Draft                                        Harvard University
Intended status: Standards Track                         Lawrence Conroy
                                                     Roke Manor Research
                                                       Kazunori Fujiwara
                                        Japan Registry Service Co., Ltd.
                                                              4 May 2009

   The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation
               Discovery System (DDDS) Application (ENUM)
                    <draft-ietf-enum-3761bis-04.txt>

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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/1id-abstracts.html

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

   This Internet-Draft will expire on October 4, 2009.

Abstract

   This document discusses the use of the Domain Name System (DNS) for
   the storage of E.164 numbers, and for resolving them into URIs that
   can be used for (for example) telephony call setup.  This document
   also describes how the DNS can be used to identify the services
   associated with an E.164 number.  This document obsoletes RFC 3761.

Copyright and License Notice
   Copyright (c) 2009 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 in effect on the date of



Bradner, Conroy & Fujiwara                                      [Page 1]

Internet-Draft                   3761bis                      4 May 2009


   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Table of Contents
   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .
   1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . .
   1.2.  Use of These Mechanisms for Private Dialing Plans  . . . . .
   2.  The ENUM Application Specifications  . . . . . . . . . . . . .
   2.1.  Application Unique String  . . . . . . . . . . . . . . . . .
   2.2.  First Well Known Rule  . . . . . . . . . . . . . . . . . . .
   2.3.  Expected Output  . . . . . . . . . . . . . . . . . . . . . .
   2.4.  Valid Databases  . . . . . . . . . . . . . . . . . . . . . .
   2.4.1.  Initial Key Construction . . . . . . . . . . . . . . . . .
   2.4.2.  Optional Name Server Additional Section Processing . . . .
   2.4.3.  Flags  . . . . . . . . . . . . . . . . . . . . . . . . . .
   2.4.4.  Services Parameters. . . . . . . . . . . . . . . . . . . .
   2.4.4.1.  ENUM Services. . . . . . . . . . . . . . . . . . . . . .
   2.4.4.2.  Compound NAPTRs and Implicit ORDER/PREFERENCE Values . .
   2.5.  The ENUM Algorithm Always Returns a Single Rule  . . . . . .
   2.6.  Case Sensitivity in ENUM . . . . . . . . . . . . . . . . . .
   3.  ENUM Clients . . . . . . . . . . . . . . . . . . . . . . . . .
   3.1.  Unsupported NAPTRs . . . . . . . . . . . . . . . . . . . . .
   3.2.  ENUM NAPTR Processing  . . . . . . . . . . . . . . . . . . .
   3.2.1.  Use of Order and Preference Fields . . . . . . . . . . . .
   3.2.2.  NAPTRs With Identical ORDER/PRIORITY Values  . . . . . . .
   3.2.3. Processing Order Value Across Domains . . . . . . . . . . .
   3.3. Non-Terminal NAPTR Processing . . . . . . . . . . . . . . . .
   3.3.1. Non-Terminal NAPTRs - Necessity . . . . . . . . . . . . . .
   3.3.2. Non-Terminal NAPTRs - Considerations  . . . . . . . . . . .
   3.3.2.1. Non-Terminal NAPTRs - General . . . . . . . . . . . . . .
   3.3.2.2. Non-Terminal NAPTRs - Loop Detection and Response . . . .
   3.3.2.3. Field content in Non-Terminal NAPTRs  . . . . . . . . . .
   3.3.2.3.1.  Flags Field Content With Non-Terminal NAPTRs . . . . .
   3.3.2.3.2.  Services Field Content with Non-Terminal NAPTRs  . . .
   3.3.2.3.3.  Regular Expression and Replacement Field Content
               with Non-terminal NAPTRs . . . . . . . . . . . . . . .
   3.4.  Backwards Compatibility  . . . . . . . . . . . . . . . . . .
   3.4.1.  Services Field Syntax  . . . . . . . . . . . . . . . . . .
   3.5. Collected Implications for ENUM Clients . . . . . . . . . . .
   3.5.1. Non_terminal NAPTR Processing . . . . . . . . . . . . . . .
   4.  ENUM Service Example . . . . . . . . . . . . . . . . . . . . .
   5. Collected Implications for ENUM Provisioning  . . . . . . . . .
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .
   7.1.  DNS Security . . . . . . . . . . . . . . . . . . . . . . . .
   7.2.  Caching Security . . . . . . . . . . . . . . . . . . . . . .
   7.3.  Call Routing Security  . . . . . . . . . . . . . . . . . . .



Bradner, Conroy & Fujiwara                                      [Page 2]

Internet-Draft                   3761bis                      4 May 2009


   7.4.  URI Resolution Security  . . . . . . . . . . . . . . . . . .
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .
   9.  Changes from RFC 3761  . . . . . . . . . . . . . . . . . . . .
   10.  References  . . . . . . . . . . . . . . . . . . . . . . . . .
   10.1.  Normative References  . . . . . . . . . . . . . . . . . . .
   11.2.  Informative References  . . . . . . . . . . . . . . . . . .
   Editor's Address . . . . . . . . . . . . . . . . . . . . . . . . .
   Copyright Statement  . . . . . . . . . . . . . . . . . . . . . . .

1.  Introduction
   This document discusses the use of the Domain Name System (DNS) for
   the storage of E.164 [E164] numbers, and for resolving them into URIs
   that can be used for (for example) telephony call setup.  This
   document also describes how the DNS can be used to identify the
   services associated with an E.164 number. This document includes a
   Dynamic Delegation Discovery System (DDDS) Application specification,
   as detailed in the document series described in [RFC3401]. This
   document obsoletes [RFC3761].

   Using the process defined in this document, International Public
   Telecommunication Numbers in the international format defined in ITU
   Recommendation E.164 [E164] (called here "E.164 numbers") can be
   transformed into DNS names. Using existing DNS services (such as
   delegation through NS records and queries for NAPTR resource
   records), one can look up the services associated with that E.164
   number. This takes advantage of standard DNS architectural features
   of decentralized control and management of the different levels in
   the lookup process.

   The domain "e164.arpa" has been assigned to provide the
   infrastructure in DNS for storage of E.164 numbers.  In order to
   facilitate distributed operations, this domain is divided into
   subdomains.  Holders of E.164 numbers which want the numbers to be
   listed in the DNS should contact the appropriate zone administrator
   as listed in the policy attached to the zone.  One should start
   looking for this information by examining the SOA resource record
   associated with the zone, just like in normal DNS operations.

   Of course, as with other domains, policies for such listings will be
   controlled on a subdomain basis and may differ in different parts of
   the world.

1.1.  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 BCP 14, RFC 2119
   [RFC2119].




Bradner, Conroy & Fujiwara                                      [Page 3]

Internet-Draft                   3761bis                      4 May 2009


   All other capitalized terms are taken from the vocabulary found in
   the DDDS algorithm specification found in RFC 3402 [RFC3402].

1.2.  Use of These Mechanisms for Private Dialing Plans
   This document describes the operation of these mechanisms in the
   context of numbers allocated according to the ITU-T recommendation
   E.164.  The same mechanisms might be used for private dialing plans.
   If these mechanisms are re-used, the suffix used for the private
   dialing plan MUST NOT be e164.arpa, to avoid conflict with this
   specification.  Parties to the private dialing plan will need to know
   the suffix used by their private dialing plan for correct operation
   of these mechanisms.  Further, the application unique string used
   SHOULD be the full number as specified, but without the leading '+',
   and such private use MUST NOT be called "ENUM".


2.  The ENUM Application Specifications
   This template defines the ENUM DDDS Application according to the
   rules and requirements found in [RFC3402].  The DDDS database used by
   this Application is found in [RFC3403], which is the document that
   defines the NAPTR DNS Resource Record type.

   ENUM is only applicable for E.164 numbers.  ENUM compliant
   applications MUST only query DNS for what it believes is an E.164
   number.  Since there are numerous dialing plans which can change over
   time, it is probably impossible for a client application to have
   perfect knowledge about every valid and dialable E.164 number.
   Therefore a client application, doing everything within its power,
   can end up with what it thinks is a syntactically correct E.164
   number which in reality is not actually valid or dialable.  This
   implies that applications MAY send DNS queries when, for example, a
   user mistypes a number in a user interface.  Because of this, there
   is the risk that collisions between E.164 numbers and non-E.164
   numbers can occur.  To mitigate this risk, the "E2U" token MUST NOT
   be provisioned into the services field of NAPTRs in domains
   associated with non-E.164 numbers.

2.1.  Application Unique String
   The Application Unique String is a fully qualified E.164 number minus
   any non-digit characters except for the '+' character which appears
   at the beginning of the number.  The "+" is kept to provide a well
   understood anchor for the AUS in order to distinguish it from other
   telephone numbers that are not part of the E.164 namespace.

   For example, the E.164 number could start out as "+44-116-496-0348".
   To ensure that no syntactic sugar is allowed into the AUS, all non-
   digits except for "+" are removed, yielding "+441164960348".




Bradner, Conroy & Fujiwara                                      [Page 4]

Internet-Draft                   3761bis                      4 May 2009


2.2.  First Well Known Rule
   The First Well Known Rule for this Application is the identity rule.
   The output of this rule is the same as the input.  This is because
   the E.164 namespace and this Application's database are organized in
   such a way that it is possible to go directly from the name to the
   smallest granularity of the namespace directly from the name itself.

   Take the previous example, the AUS is "+441164960348".  Applying the
   First Well Known Rule produces the exact same string,
   "+441164960348".

2.3.  Expected Output
   The output of the last DDDS loop is a Uniform Resource Identifier in
   its absolute form according to the 'absoluteURI' production in the
   Collected ABNF found in [RFC3986].

2.4.  Valid Databases
   At present only one DDDS Database is specified for this Application.
   "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS
   Database" [RFC3403] specifies a DDDS Database that uses the NAPTR DNS
   resource record to contain the rewrite rules.  The Keys for this
   database are encoded as domain names.

2.4.1 Initial Key Construction
   The output of the First Well Known Rule for the ENUM Application is
   the E.164 number minus all non-digit characters except for the "+".
   In order to convert this to a unique key in this Database the string
   is converted into a domain name according to this algorithm:

      1.  Remove all characters with the exception of the digits.  For
         example, example, given the E.164 number "+44-20-7946-0148" the
         First Well Known Rule produces the string "+442079460148".
         This step would simply remove the leading "+", producing
         "442079460148".
      2.  Put dots (".") between each digit.  Example:
         4.4.2.0.7.9.4.6.0.1.4.8
      3.  Reverse the order of the digits.  Example:
         8.4.1.0.6.4.9.7.0.2.4.4
      4.  Append the string ".e164.arpa." to the end.  Example:
         8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.

   This domain name is used to request NAPTR records which may contain
   the end result or, if the flags field is empty, produces new keys in
   the form of domain names from the DNS.

   The character set used to encode the substitution expression is
   UTF-8.  The allowed input characters are all those characters that
   are allowed anywhere in an E.164 number.  The characters allowed to



Bradner, Conroy & Fujiwara                                      [Page 5]

Internet-Draft                   3761bis                      4 May 2009


   be in a Key are those that are currently defined for DNS domain
   names.

2.4.2.  Optional Name Server Additional Section Processing
   Some nameserver implementations attempt to be intelligent about items
   that are inserted into the additional information section of a given
   DNS response.  For example, BIND will attempt to determine if it is
   authoritative for a domain whenever it encodes one into a packet.  If
   it is, then it will insert any A records it finds for that domain
   into the additional information section of the answer until the
   packet reaches the maximum length allowed.  It is therefore
   potentially useful for a client to check for this additional
   information.

   It is also easy to contemplate an ENUM enhanced nameserver that
   understands the actual contents of the NAPTR records it is serving
   and inserts more appropriate information into the additional
   information section of the response.  Thus, DNS servers MAY interpret
   Flag values and use that information to include appropriate resource
   records in the Additional Information portion of the DNS packet.
   Clients are encouraged to check for additional information but are
   not required to do so.  See the Additional Information Processing
   section of [RFC3403], Section 4.2 for more information on NAPTR
   records and the Additional Information section of a DNS response
   packet.


2.4.3.  Flags
   This Database contains a field that contains flags that signal when
   the DDDS algorithm has finished.  At this time only one flag, "U", is
   defined.  This means that this Rule is the last one and that the
   output of the Rule is a URI [RFC3986].  See [RFC3404].

   If a client encounters a record with an unknown flag, it MUST ignore
   it and move to the next Rule.  This test takes precedence over any
   ordering since flags can control the interpretation placed on fields.

   A novel flag might change the interpretation of the regexp and/or
   replacement fields such that it is impossible to determine if a
   record matched a given target.

   If this flag is not present then this rule is non-terminal.  If a
   Rule is non-terminal then clients MUST use the Key produced by this
   Rewrite Rule as the new Key in the DDDS loop (i.e., causing the
   client to query for new NAPTR records at the domain name that is the
   result of this Rule).

2.4.4.  Services Parameters



Bradner, Conroy & Fujiwara                                      [Page 6]

Internet-Draft                   3761bis                      4 May 2009


   Service Parameters for this Application take the following form and
   are found in the Service field of the NAPTR record that holds a
   terminal rule. Where the NAPTR holds a non-terminal Rule, the
   Services field SHOULD be empty, and clients SHOULD ignore its
   content.

      service-field = "E2U" 1*(servicespec)
      servicespec   = "+" enumservice
      enumservice   = type 0*(subtypespec)
      subtypespec   = ":" subtype
      type          = 1*32(ALPHA / DIGIT / "-")
      subtype       = 1*32(ALPHA / DIGIT / "-")

   In other words, a non-optional "E2U" (used to denote ENUM only
   Rewrite Rules in order to mitigate record collisions) followed by one
   or more Enumservices which indicate the class of functionality a
   given end point offers.  Each Enumservice is indicated by an initial
   '+' character.

2.4.4.1.  ENUM Services
   Enumservices may be specified and registered via the process defined
   in "Guide and Template for IANA Registrations of Enumservices"
   [SV_GUIDE].  This registration process is not open to any Enumservice
   that has '-' as the second character in its type string.

   In particular, this registration process is not open to Enumservice
   types starting with the facet "X-". This "X-" facet is reserved for
   experimental or trial use, and any such Enumservices cannot be
   registered using the normal process.

   Finally, any Enumservice type that starts with the facet "P-" is
   intended for use exclusively on private networks. As such, NAPTRs
   containing Enumservice types starting "P-" should not be seen on the
   global Internet. Even if an ENUM client recognizes and can engage in
   the Enumservice, it may be incapable of resolving the URI generated
   by the containing NAPTR. These Enumservices WILL NOT be registered.

   Such Enumservices MUST NOT be provisioned in any system that provides
   answers to DNS queries for NAPTR resource record sets from entities
   outside the private network context in which these Enumservices are
   intended for use.  Unless an ENUM client is sure that it is connected
   to the private network for which these NAPTRs are provisioned and
   intended, it MUST discard any NAPTR with an Enumservice type that
   starts with the "P-" facet.

2.4.4.2.  Compound NAPTRs and Implicit ORDER/PREFERENCE Values
   It is possible to have more than one Enumservice associated with a
   single NAPTR.  These Enumservices share the same Regexp field and so



Bradner, Conroy & Fujiwara                                      [Page 7]

Internet-Draft                   3761bis                      4 May 2009


   generate the same URI.  Such a "compound" NAPTR could well be used to
   indicate a mobile phone that supports both "voice:tel" and "sms:tel"
   Enumservices.  The Services field in that case would be
   "E2U+voice:tel+sms:tel".

   A compound NAPTR can be treated as a set of NAPTRs that each hold a
   single Enumservice.  These reconstructed NAPTRs share the same ORDER
   and PREFERENCE/PRIORITY field values but should be treated as if each
   had a logically different priority.  ENUM clients SHOULD process the
   Enumservices within a compound NAPTR in a left-to-right sequence.
   ENUM provisioning systems SHOULD assume that such a processing order
   will be used and provision the Enumservices within a compound NAPTR
   accordingly.

2.5.  The ENUM Algorithm Always Returns a Single Rule
   The ENUM algorithm always returns a single rule.  Specific
   applications may have application-specific knowledge or facilities
   that allow them to present multiple results or speed selection, but
   these should never change the operation of the algorithm.

2.6.  Case Sensitivity in ENUM
   The only place where NAPTR field content is case sensitive is in any
   static text in the Repl sub-field of the Regexp field.  Everywhere
   else, case-insensitive processing SHOULD be used.

3. ENUM Clients

3.1. Unsupported NAPTRs
   An ENUM client MAY discard a NAPTR received in response to an ENUM
   query because:
   o  the NAPTR is syntactically or semantically incorrect,
   o  the NAPTR has a different (non-empty) DDDS Application identifier
      from the 'E2U' used in ENUM,
   o  the NAPTR's Extended Regular Expression (ERE) does not match the
      Application Unique String for this ENUM query,
   o  the ENUM client does not recognize any Enumservice in that NAPTR,
   o  this NAPTR (only) contains an Enumservice that is unsupported.

   These conditions SHOULD NOT cause the whole ENUM query to terminate,
   and processing SHOULD continue with the next NAPTR in the returned
   Resource Record Set (RRSet).

   When an ENUM client encounters a compound NAPTR (i.e., one containing
   more than one Enumservice -- see Section 2.4.4.2) and cannot process
   or cannot recognize one of the Enumservices within it, that ENUM
   client SHOULD ignore this Enumservice and continue with the next
   Enumservice within this NAPTR's Services field, discarding the NAPTR
   only if it cannot handle any of the Enumservices contained.  These



Bradner, Conroy & Fujiwara                                      [Page 8]

Internet-Draft                   3761bis                      4 May 2009


   conditions SHOULD NOT be considered errors.

   ENUM uses regular-expression processing when generating URIs from the
   Regexp field of "terminal" NAPTRs.  Just as with all uses of regular
   expressions, there is a potential for buffer overrun when generating
   this output.  There may be repeated back-reference patterns in a
   NAPTR's Repl sub-field, and the output these generate may consume a
   considerable amount of buffer space.

   Even if an ENUM client would normally encounter only NAPTRs with
   short URIs, it may also receive NAPTRs with repeated back-reference
   patterns in their Repl sub-fields that could generate strings longer
   than the client's buffer.  Such NAPTRs may have been misconfigured
   accidentally or by design.  The client MUST NOT fail in this case. It
   SHOULD NOT discard the entire ENUM query, but instead just discard
   the NAPTR that would otherwise have caused this overrun.

   If a problem is detected when processing an ENUM query across
   multiple domains (by following non-terminal NAPTR references), then
   the ENUM query SHOULD NOT be abandoned, but instead processing SHOULD
   continue at the next NAPTR after the non-terminal NAPTR that referred
   to the domain in which the problem would have occurred.  See Section
   3.3.2.2 for more details.


3.2.  ENUM NAPTR Processing

   ENUM is a DDDS Application, and the way in which NAPTRs in an RRSet
   are processed reflects this.  The details are described in Section
   3.3 of RFC3402].  The client is expected to sort the records it
   receives into a sequence and then process those records in that
   sequence.  The sequence reflects the ORDER field value ("lowest value
   is first") and PREFERENCE/PRIORITY field value (again, lowest value
   first) in each of the NAPTRs.  The ORDER field value is the major, or
   most significant, sort term and the PREFERENCE/PRIORITY field value
   is the minor, or least significant, sort term. The combination of
   ORDER and PREFERENCE/PRIORITY field values indicates the sequence
   chosen by the publisher of this data, and NAPTRs will be considered
   in this sequence. Subsequent NAPTRs with worse ORDER values MUST only
   be dealt with once the current ones with a better ORDER value have
   been processed.

   Once sorted into a sequence reflecting ORDER and PREFERENCE/PRIORITY
   values, other fields are also considered during evaluation of
   retrieved NAPTRs. ENUM clients will take into account the Flags field
   value, the Services field value, and the Regexp ERE sub-field, along
   with the ORDER and PREFERENCE/PRIORITY field values. Local policies
   or local knowledge may play a factor in the decision process, once a



Bradner, Conroy & Fujiwara                                      [Page 9]

Internet-Draft                   3761bis                      4 May 2009


   NAPTR has reached that point in the sequence at which it is
   considered.


3.2.1. Use of Order and Preference fields
   NAPTRs in ENUM zones that hold incorrect ORDER values can cause major
   problems.  [RFC3403] highlights that having both ORDER and
   PREFERENCE/PRIORITY fields is a historical artifact of the NAPTR
   resource record type.  It is reasonable to have a common default
   value for the ORDER field, relying on the PREFERENCE/PRIORITY field
   to indicate the preferred sort.

   The ORDER field value is the major sort term, and the
   PREFERENCE/PRIORITY field value is the minor sort term.  Thus, one
   should expect to have a set of NAPTRs in a zone with identical ORDER
   field values and different PREFERENCE/PRIORITY field values; not the
   other way around.

   To avoid common interoperability issues, it is recommended that ENUM
   NAPTRs SHOULD hold a default value in their ORDER field.


3.2.2. NAPTRs with Identical ORDER/PRIORITY Values
   From experience, it has been learned that there are zones that hold
   discrete NAPTRs with identical ORDER and identical PREFERENCE/
   PRIORITY field values.  This will lead to indeterminate client
   behavior and so SHOULD NOT normally occur.

   Such a condition indicates that these NAPTRs are truly identical in
   priority and that there is no preference between the services these
   NAPTRs offer.  Implementers SHOULD NOT assume that the DNS will
   deliver NAPTRs within an RRSet in a particular sequence.

3.2.3. Processing Order Value Across Domains
   Using a different ORDER field value in different domains is
   unimportant for most queries.  However, DDDS includes a mechanism for
   continuing a search for NAPTRs in another domain by including a
   reference to that other domain in a "non-terminal" NAPTR.  The
   treatment of non-terminal NAPTRs is covered in the next section.  If
   they are supported, then the way that ORDER and PREFERENCE/PRIORITY
   field values are processed is affected.

   ENUM implementations MUST consider the ORDER and PREFERENCE/PRIORITY
   values only within the context of the domain currently being
   processed in an ENUM query. These values MUST be disregarded when
   processing other RRSets in the query.

3.3. Non-Terminal NAPTR Processing



Bradner, Conroy & Fujiwara                                     [Page 10]

Internet-Draft                   3761bis                      4 May 2009


3.3.1. Non-Terminal NAPTRs - Necessity
   Consider an ENUM RRSet that contains a non-terminal NAPTR record.
   This non-terminal NAPTR holds, as its target, another domain that has
   a set of NAPTRs.  In effect, this is similar to the non-terminal
   NAPTR being replaced by the NAPTRs contained in the domain to which
   it points.

   It is possible to have a non-terminal NAPTR in a domain that is,
   itself, pointed to by another non-terminal NAPTR.  Thus, a set of
   domains forms a "chain", and the list of NAPTRs to be considered is
   the set of all NAPTRs contained in all of the domains in that chain.
   Given that, in principle, a non-terminal NAPTR can be replaced by the
   NAPTRs in the domain to which it points, support of non-terminal
   NAPTRs is not needed and non-terminal NAPTRs may not be useful.
   Furthermore, some existing ENUM clients do not support non-terminal
   NAPTRs and ignore them if received.

   As current support is limited, non-terminal NAPTRs SHOULD NOT be used
   in ENUM unless it is clear that all of the ENUM clients this
   environment supports can process these.

3.3.2. Non-Terminal NAPTRs - Considerations
   The following specific issues need to be considered if non-terminal
   NAPTRs are to be supported in a particular environment.  These issues
   are gleaned from experience and indicate the kinds of conditions that
   should be considered before support for non-terminal NAPTRs is
   contemplated.

3.3.2.1. Non-Terminal NAPTRs - General
   A non-terminal NAPTR in one RRSet refers to the NAPTRs contained in
   another domain.  The NAPTRs in the domain referred to by the non-
   terminal NAPTR may have a different ORDER value from that in the
   referring non-terminal NAPTR.  See Section 3.2.3 for details.

3.3.2.2. Non-Terminal NAPTRs - Loop Detection and Response
   Where a chain of non-terminal NAPTRs refers back to a domain already
   traversed in the current query, a "non-terminal" or referential loop
   is implied.  An implementation MAY treat a chain of more than 5
   domains traversed during a single ENUM query as an indication that a
   self-referential loop has been entered.

   There are many techniques that can be used to detect such a loop, but
   the simple approach of counting the number of domains queried in the
   current ENUM query suffices.

   Where a loop has been detected, processing SHOULD continue at the
   next NAPTR in the referring domain (i.e., after the non-terminal
   NAPTR that included the reference that triggered the loop detection).



Bradner, Conroy & Fujiwara                                     [Page 11]

Internet-Draft                   3761bis                      4 May 2009


3.3.2.3. Field content in Non-Terminal NAPTRs
   The set of specifications defining DDDS and its applications are
   complex and multi-layered.  This reflects the flexibility that the
   system provides but does mean that some of the specifications need
   clarification as to their interpretation, particularly where non-
   terminal rules are concerned.

3.3.2.3.1.  Flags Field Content with Non-Terminal NAPTRs
   The Flags field will be empty in non-terminal NAPTRs encountered in
   ENUM processing.  ENUM does not have any other way to indicate a non-
   terminal NAPTR.

3.3.2.3.2.  Services field Content with Non-Terminal NAPTRs
   In a non-terminal NAPTR encountered in an ENUM query, the Services
   field SHOULD be empty, and clients SHOULD ignore any content it
   contains.

   Non-terminal NAPTRs with an empty Services field are not specific to
   any DDDS Application.  Thus, other means must be used to ensure a
   non-terminal NAPTR that is intended only for a particular DDDS
   Application cannot be encountered during a lookup for another DDDS
   Application (for example, by ensuring that the same domain is not
   used to host NAPTRs for more than one such DDDS Application).

3.3.2.3.3.  Regular Expression and Replacement Field Content with Non-
   Terminal NAPTRs
   [RFC3403] is specific; Regexp and Replacement fields are mutually
   exclusive. This means that if the Regexp element is not empty, then
   the Replacement element must be empty, and vice versa.  However,
   [RFC3403] does not specify which is used with terminal and non-
   terminal rules.

   A Replacement element cannot be used in ENUM for terminal rules, as
   only non-terminal rules ("non-terminal NAPTRs") have a domain as
   their output in ENUM: terminal ENUM rules generate a URI instead. The
   alternative Regexp element may be used either to generate a domain
   name as the next key to be used in the non-terminal case or to
   generate the output of the DDDS Application.

   However, generating an ENUM domain name from the Regexp field is
   difficult at best and impossible for the general case of a variable-
   length telephone number, or one that has more than 9 digits.  Thus,
   the Regexp field is inappropriate for non-terminal rules encountered
   during ENUM processing.

   To clarify, the target domain of a non-terminal ENUM NAPTR MUST be
   placed in the (non-empty) Replacement field.  This field MUST be
   interpreted as holding the domain name that forms the next key output



Bradner, Conroy & Fujiwara                                     [Page 12]

Internet-Draft                   3761bis                      4 May 2009


   from this non-terminal rule. Conversely, the Regexp field MUST be
   empty in a non-terminal NAPTR encountered in ENUM processing, and
   ENUM clients MUST ignore its content.

3.4.  Backwards Compatibility

3.4.1.  Services Field Syntax
   [RFC2915] and [RFC2916] have been obsoleted by [RFC3401] - [RFC3404]
   and by this document.  However, [RFC3824] suggests that ENUM clients
   should be prepared to accept NAPTRs with the obsolete syntax.  Thus,
   an ENUM client implementation may have to deal with both forms.  This
   need not be difficult.  For example, an implementation could process
   the Services field into a set of tokens and expect exactly one of
   these tokens to be "E2U".  In this way, the ENUM client might be
   designed to handle both the old and the current forms without added
   complexity.

   To facilitate this method, IANA should reject any request to register
   an Enumservice with the label "E2U", and this request is included in
   the IANA considerations of [SV_GUIDE].

   ENUM clients MUST support ENUM NAPTRs according to the service field
   syntax specified in Section 2.4.2.  ENUM clients SHOULD also support
   ENUM NAPTRs according to the obsolete syntax of [RFC2916]; there are
   still zones that hold "old" syntax NAPTRs.

   ENUM zones MUST NOT be provisioned with NAPTRs according to the
   obsolete form defined in [RFC2916], and MUST be provisioned with
   NAPTRs in which the Services field is according to the specification
   of Section 2.4.2 of this document.

3.5. Collected Implications for ENUM Clients
   ENUM clients SHOULD NOT discard NAPTRs in which they detect
   characters outside the US-ASCII printable range (0x20 to 0x7E
   hexadecimal).

   ENUM clients MAY discard NAPTRs that have octets in the Flags,
   Services, or Regexp fields that have byte values outside the US-ASCII
   equivalent range (i.e., byte values above 0x7F).  Clients MUST be
   ready to encounter NAPTRs with such values without failure.

   ENUM clients SHOULD NOT assume that the delimiter is the last
   character of the Regexp field.

      Unless they are sure that in their environment this is the case,
      in general an ENUM client may still encounter NAPTRs that have
      been provisioned with a following 'i' (case-insensitive) flag,
      even though that flag has no effect at all in an ENUM scenario.



Bradner, Conroy & Fujiwara                                     [Page 13]

Internet-Draft                   3761bis                      4 May 2009


   ENUM clients SHOULD discard NAPTRs that have more or less than 3
   unescaped instances of the delimiter character within the Regexp
   field.

      In the spirit of being liberal with what it will accept, if the
      ENUM client is sure how the Regexp field should be interpreted,
      then it may choose to process the NAPTR even in the face of an
      incorrect number of unescaped delimiter characters.  If it is not
      clear how the Regexp field should be interpreted, then the client
      must discard the NAPTR.

   Where the ENUM client presents a list of possible URLs to the end
   user for his or her choice, it MAY present all NAPTRs -- not just the
   ones with the highest currently unprocessed ORDER field value.  The
   client SHOULD keep to the ORDER and PREFERENCE/PRIORITY values
   specified by the Registrant.

   ENUM clients SHOULD accept all NAPTRs with identical ORDER and
   identical PREFERENCE/PRIORITY field values, and process them in the
   sequence in which they appear in the DNS response.  (There is no
   benefit in further randomizing the order in which these are
   processed, as intervening DNS Servers might have done this already).

   ENUM clients receiving compound NAPTRs (i.e., ones with more than one
   Enumservice) SHOULD process these Enumservices using a left-to-right
   sort ordering, so that the first Enumservice to be processed will be
   the leftmost one, and the last will be the rightmost one.

   ENUM clients SHOULD consider the ORDER field value only when sorting
   NAPTRs within a single RRSet.  The ORDER field value SHOULD NOT be
   taken into account when processing NAPTRs across a sequence of DNS
   queries created by traversal of non-terminal NAPTR references.

   ENUM clients MUST be ready to process NAPTRs that use a different
   character from '!' as their Regexp Delimiter without failure.

   ENUM clients MUST be ready to process NAPTRs that have non-trivial
   patterns in their ERE sub-field values without failure.

   ENUM clients MUST be ready to process NAPTRs with a DDDS Application
   identifier other than 'E2U' without failure.

   ENUM clients MUST be ready to process NAPTRs with many copies of
   back-reference patterns within the Repl sub-field without failure
   (see also Section 3.1).

   If a NAPTR is discarded, this SHOULD NOT cause the whole ENUM query
   to terminate and processing SHOULD continue with the next NAPTR in



Bradner, Conroy & Fujiwara                                     [Page 14]

Internet-Draft                   3761bis                      4 May 2009


   the returned Resource Record Set (RRSet).

   When an ENUM client encounters a compound NAPTR (i.e., one containing
   more than one Enumservice) and cannot process or cannot recognize one
   of the Enumservices within it, that ENUM client SHOULD ignore this
   Enumservice and continue with the next Enumservice within this
   NAPTR's Services field, discarding the NAPTR only if it cannot handle
   any of the Enumservices contained.  These conditions SHOULD NOT be
   considered errors.

   ENUM clients MUST support ENUM NAPTRs according to syntax defined in
   Section 2.4.2. ENUM clients SHOULD also support ENUM NAPTRs according
   to the obsolete syntax of [RFC2916]; there are still zones that hold
   "old" syntax NAPTRs.
    Unless an ENUM client is sure that it is connected to the private
   network for which these NAPTRs are provisioned and intended, it MUST
   discard any NAPTR with an Enumservice type that starts with the "P-"
   facet.

3.5.1. Non-terminal NAPTR Processing
   ENUM clients MUST be ready to process NAPTRs with an empty Flags
   field ("non-terminal" NAPTRs) without failure.  More generally, non-
   terminal NAPTR processing SHOULD be implemented, but ENUM clients MAY
   discard non-terminal NAPTRs they encounter.

   ENUM clients SHOULD ignore any content of the Services field when
   encountering a non-terminal NAPTR with an empty Flags field.

   ENUM clients receiving a non-terminal NAPTR with an empty Flags field
   MUST treat the Replacement field as holding the domain name to be
   used in the next round of the ENUM query.  An ENUM client MUST
   discard such a non-terminal NAPTR if the Replacement field is empty
   or does not contain a valid domain name.  By definition, it follows
   that the Regexp field will be empty in such a non-terminal NAPTR.  If
   present in a non-terminal NAPTR, a non-empty Regexp field MUST be
   ignored by ENUM clients.

   If a problem is detected when processing an ENUM query across
   multiple domains (by following non-terminal NAPTR references), then
   the ENUM query SHOULD NOT be abandoned, but instead processing SHOULD
   continue at the next NAPTR after the non-terminal NAPTR that referred
   to the domain in which the problem would have occurred.

   If all NAPTRs in a domain traversed as a result of a reference in a
   non-terminal NAPTR have been discarded, then the ENUM client SHOULD
   continue its processing with the next NAPTR in the "referring" RRSet
   (i.e., the one including the non-terminal NAPTR that caused the
   traversal).



Bradner, Conroy & Fujiwara                                     [Page 15]

Internet-Draft                   3761bis                      4 May 2009


   ENUM clients MAY consider a chain of more than 5 "non-terminal"
   NAPTRs traversed in a single ENUM query as an indication that a
   referential loop has been entered.

   Where a domain is about to be entered as the result of a reference in
   a non-terminal NAPTR, and the ENUM client has detected a potential
   referential loop, then the client SHOULD discard the non-terminal
   NAPTR from its processing and continue with the next NAPTR in its
   list.  It SHOULD NOT make the DNS query indicated by that non-
   terminal NAPTR.


4.  ENUM Service Example

   $ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.
      NAPTR 100 50 "u" "E2U+sip" "!^.*$!sip:info@example.com!" .
      NAPTR 100 51 "u" "E2U+h323" "!^.*$!h323:info@example.com!" .
      NAPTR 100 52 "u" "E2U+email:mailto"
            "!^.*$!mailto:info@example.com!" .

   This describes that the domain 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. is
   preferably contacted by SIP, secondly via H.323 for voice, and
   thirdly by SMTP for messaging.  Note that the Enumservice tokens
   "sip", "h323", and "email" are Enumservice Types registered with
   IANA, and they have no implicit connection with the protocols or URI
   schemes with the same names.

   In all cases, the next step in the resolution process is to use the
   resolution mechanism for each of the protocols, (specified by the URI
   schemes sip, h323 and mailto) to know what node to contact.


5. Collected Implications for ENUM Provisioning
   ENUM NAPTRs SHOULD NOT include characters outside the printable US-
   ASCII equivalent range (U+0020 to U+007E) unless it is clear that all
   ENUM clients they are designed to support will be able to process
   such characters correctly.  If ENUM zone provisioning systems require
   non-ASCII characters, these systems SHOULD encode the non-ASCII data
   to emit only US-ASCII characters by applying the appropriate
   mechanism ([RFC3492], [RFC3987]).  Non-printable characters SHOULD
   NOT be used, as ENUM clients may need to present NAPTR content in a
   human-readable form.

   The case-sensitivity flag ('i') is inappropriate for ENUM, and SHOULD
   NOT be provisioned into the Regexp field of E2U NAPTRs.

   ENUM zone provisioning systems SHOULD use '!'  (U+0021) as their
   Regexp delimiter character.



Bradner, Conroy & Fujiwara                                     [Page 16]

Internet-Draft                   3761bis                      4 May 2009


   If the Regexp delimiter is a character in the static text of the Repl
   sub-field, it MUST be "escaped" using the escaped-delimiter
   production of the BNF specification shown in Section 3.2 of [RFC3402]
   (i.e., "\!", U+005C U+0021).  Note that when a NAPTR resource record
   is entered in DNS master file syntax, the backslash itself must be
   escaped using a second backslash.

   If present in the ERE sub-field of an ENUM NAPTR, the literal
   character '+' MUST be escaped as "\+" (i.e. U+005C U+002B).  Note
   that, as always, when a NAPTR resource record is entered in DNS
   master file syntax, the backslash itself must be escaped using a
   second backslash.

   The Registrant and the ENUM zone provisioning system he or she uses
   SHOULD NOT rely on ENUM clients solely taking account of the value of
   the ORDER and the PREFERENCE/PRIORITY fields in ENUM NAPTRs.  Thus, a
   Registrant SHOULD place into his or her zone only contacts that he or
   she is willing to support; even those with the worst ORDER and
   PREFERENCE/PRIORITY values MAY be selected by an end user.

   Many apparent mistakes in ORDER and PREFERENCE/PRIORITY values have
   been detected in provisioned ENUM zones.  To avoid these common
   interoperability issues, provisioning systems SHOULD NOT use
   different ORDER field values for NAPTRs in a Resource Record Set
   (RRSet).  To generalize, all ENUM NAPTRs SHOULD hold a default value
   in their ORDER field.  A value of "100" is recommended, as it seems
   to be used in most provisioned domains.

   Multiple NAPTRs with identical ORDER and identical PREFERENCE/
   PRIORITY field values SHOULD NOT be provisioned into an RRSet unless
   the intent is that these NAPTRs are truly identical and there is no
   preference between them.  Implementers SHOULD NOT assume that the DNS
   will deliver NAPTRs within an RRSet in a particular sequence.

   An ENUM zone provisioning system SHOULD assume that, if it generates
   compound NAPTRs, the Enumservices will normally be processed in left-
   to-right order within such NAPTRs.

   ENUM zone provisioning systems SHOULD assume that, once a non-
   terminal NAPTR has been selected for processing, the ORDER field
   value in a domain referred to by that non-terminal NAPTR will be
   considered only within the context of that referenced domain (i.e.,
   the ORDER value will be used only to sort within the current RRSet
   and will not be used in the processing of NAPTRs in any other RRSet).

   Whilst this client behavior is non-compliant, ENUM provisioning
   systems and their users should be aware that some ENUM clients have
   been detected with poor (or no) support for non-trivial ERE sub-field



Bradner, Conroy & Fujiwara                                     [Page 17]

Internet-Draft                   3761bis                      4 May 2009


   expressions.

   ENUM provisioning systems SHOULD be cautious in the use of multiple
   back-reference patterns in the Repl sub-field of NAPTRs they
   provision.  Some clients have limited buffer space for character
   expansion when generating URIs (see also Section 3.1).  These
   provisioning systems SHOULD check the back-reference replacement
   patterns they use, ensuring that regular expression processing will
   not produce excessive-length URIs.

   As current support is limited, non-terminal NAPTRs SHOULD NOT be
   provisioned in ENUM zones unless it is clear that all ENUM clients
   that this environment supports can process these.

   When populating a set of domains with NAPTRs, ENUM zone provisioning
   systems SHOULD NOT configure non-terminal NAPTRs so that more than 5
   such NAPTRs will be processed in an ENUM query.

   In a non-terminal NAPTR encountered in an ENUM query (i.e., one with
   an empty Flags field), the Services field SHOULD be empty.

   A non-terminal NAPTR MUST include its target domain in the (non-
   empty) Replacement field.  This field MUST be interpreted as holding
   the domain name that forms the next key output from this non-terminal
   rule.  The Regexp field MUST be empty in a non-terminal NAPTR
   intended to be encountered during an ENUM query.

   ENUM zones MUST NOT be provisioned with NAPTRs according to the
   obsolete form, and MUST be provisioned with NAPTRs in which the
   Services field is according to Section 2.4.2 of this document.

   Enumservices in which the Enumservice type starts with the facet "P-"
   MUST NOT be provisioned in any system that provides answers to DNS
   queries for NAPTR resource record sets from entities outside the
   private network context in which these Enumservices are intended for
   use.


6.  IANA Considerations
   RFC 2916 and then RFC 3761 (which this document replaces) requested
   IANA to delegate the E164.ARPA domain following instructions to be
   provided by the IAB.  The domain was delegated according to those
   instructions.  Names within this zone are to be delegated to parties
   according to the ITU-T Recommendation E.164.  The names allocated
   should be hierarchic in accordance with ITU-T Recommendation E.164,
   and the codes should be assigned in accordance with that
   Recommendation.




Bradner, Conroy & Fujiwara                                     [Page 18]

Internet-Draft                   3761bis                      4 May 2009


   The IAB is to coordinate with ITU-T TSB if the technical contact for
   the domain e164.arpa is to change, as ITU-T TSB has an operational
   working relationship with this technical contact which needs to be
   reestablished.

   Delegations in the zone e164.arpa (not delegations in delegated
   domains of e164.arpa) should be done after Expert Review, and the
   IESG will appoint a designated expert.

   See [SV_GUIDE] for Enumservice-related IANA Considerations.


7.  Security Considerations

7.1.  DNS Security
   As ENUM uses DNS, which in its current form is an insecure protocol,
   there is no mechanism for ensuring that the data one gets back is
   authentic.  As ENUM is deployed on the global Internet, it is
   expected to be a popular target for various kind of attacks, and
   attacking the underlying DNS infrastructure is one way of attacking
   the ENUM service itself.

   There are multiple types of attacks that can happen against DNS that
   ENUM implementations should consider.  See Threat Analysis of the
   Domain Name System [RFC3833] for a review of the various threats to
   the DNS.

   Because of these threats, a deployed ENUM service SHOULD include
   mechanisms to ameliorate these threats.  Most of the threats can be
   solved by verifying the authenticity of the data via mechanisms such
   as DNS Security (DNSSEC) [RFC4033].  Others, such as Denial Of
   Service attacks, cannot be solved by data authentication.  It is
   important to remember that these threats include not only the NAPTR
   lookups themselves, but also the various records needed for the
   services to be useful (for example NS, MX, SRV and A records).

   Even if DNSSEC is deployed, a service that uses ENUM for address
   translation should not blindly trust that the peer is the intended
   party as DNSSEC deployment cannot protect against every kind of
   attack on DNS.  A service should always authenticate the peers as
   part of the setup process for the service itself and never blindly
   trust any kind of addressing mechanism.

   Finally, as an ENUM service will be implementing some type of
   security mechanism, software which implements ENUM MUST be prepared
   to receive DNSSEC and other standardized DNS security responses,
   including large responses, EDNS0 signaling, unknown RRs, and so on.




Bradner, Conroy & Fujiwara                                     [Page 19]

Internet-Draft                   3761bis                      4 May 2009


7.2.  Caching Security
   The caching in DNS can make the propagation time for a change take
   the same amount of time as the time to live for the NAPTR records in
   the zone that is changed.  The use of this in an environment where
   IP-addresses are dynamically assigned (for example, when using DHCP
   [RFC2131]) must therefore be done very carefully.

7.3.  Call Routing Security
   There are a number of countries (and other numbering environments) in
   which there are multiple providers of call routing and number/name-
   translation services.  In these areas, any system that permits users,
   or putative agents for users, to change routing or supplier
   information may provide incentives for changes that are actually
   unauthorized (and, in some cases, for denial of legitimate change
   requests).  Such environments should be designed with adequate
   mechanisms for identification and authentication of those requesting
   changes and for authorization of those changes.

7.4.  URI Resolution Security
   A large amount of Security Issues have to do with the resolution
   process itself, and use of the URIs produced by the DDDS mechanism.
   Those have to be specified in the registration of the Enumservice
   used, as specified in "Guide and Template for IANA Registrations of
   Enumservices" [SV_GUIDE].

8.  Acknowledgements
   This document is an update of RFC 3761, which was edited by Patrik
   Faltstrom and Michael Mealling.  Please see the Acknowledgements
   section in that RFC for additional acknowledgements.

9.  Changes from RFC 3761
   Two sections have been added explaining the implied protocol
   requirements for use of NAPTRs according to this specification. These
   have been collected from experience of ENUM deployment.

   Clarifications include the required use of Replacement field in non-
   terminal NAPTRs (Section 3.3.2.3.3) and that string matching is case
   insensitive (Section 2.6).

   Substantive changes include removing the discussion of registration
   mechanisms, (now specified in "Guide and Template for IANA
   Registrations of Enumservices" [SV_GUIDE]), adding "-" as a valid
   character in the type and subtype fields in the Services Parameters
   (Section 2.4.4) and adding the "P-" private service type (Section
   3.4).

10.  References




Bradner, Conroy & Fujiwara                                     [Page 20]

Internet-Draft                   3761bis                      4 May 2009


10.1.  Normative References

   [E164] ITU-T, "The International Public Telecommunication Number
      Plan", Recommendation E.164, February 2005.
   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol", RFC
      2131, March 1997.
   [RFC3402]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
      Part Two: The Algorithm", RFC 3402, October 2002.
   [RFC3403]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
      Part Three: The Domain Name System (DNS) Database", RFC 3403,
      October 2002.
   [RFC3404]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
      Part Four: The Uniform Resource Identifiers (URI)", RFC 3404,
      October 2002.
   [RFC3492]  Costello, A., "Punycode: A Bootstring encoding of Unicode
      for Internationalized Domain Names in Applications (IDNA)", RFC
      3492, March 2003.
   [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.
   [RFC3987]  Duerst, M. and M. Suignard, "Internationalized Resource
      Identifiers (IRIs)", RFC 3987, January 2005.
   [SV_GUIDE] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "Guide and
      Template for IANA Registrations of Enumservices", draft-ietf-enum-
      enumservices-guide-06.txt (work in progress), November 2007.

10.2.  Informative References
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
      Requirement Levels", BCP 14, RFC 2119, March 1997.
   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
      Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
      January 2005.
   [RFC3401]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
      Part One: The Comprehensive DDDS", RFC 3401, October 2002.
   [RFC3833]  Atkins, D. and R. Austein, "Threat Analysis of the Domain
      Name System (DNS)", RFC 3833, August 2004.
   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
      Rose, "DNS Security Introduction and Requirements", RFC 4033,
      March 2005.

Author's Addresses

   Scott Bradner
   Harvard University
   29 Oxford St.
   Cambridge MA 02138
   Phone: +1 617 495 3864
   Email: sob@harvard.edu



Bradner, Conroy & Fujiwara                                     [Page 21]

Internet-Draft                   3761bis                      4 May 2009


   Lawrence Conroy
   Roke Manor Research
   Roke Manor
   Old Salisbury Lane
   Romsey
   United Kingdom

   Phone: +44-1794-833666
   Email: lconroy@insensate.co.uk
   URI:   http://www.sienum.co.uk


   Kazunori Fujiwara
   Japan Registry Service Co., Ltd.
   Chiyoda First Bldg. East 13F
   3-8-1 Nishi-Kanda Chiyoda-ku
   Tokyo 101-0165
   JAPAN

   Email: fujiwara@jprs.co.jp
   URI:   http://jprs.jp/en/


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



change log - RFC Editor - please remove this section for publication

version 01 -> 02
   clean up English - many places
   removed Registration mechanism for Enumservices section
   removed IANA considerations - point to draft-ietf-enum-enumservices-
   guide ,br replace DNS Security Threats in section 6.1 with a pointer
   to RFC 3833
   fold in text from the ENUM Experiences ID - many places


version 02 -> 03
   fixed minor typos
   revised section 2.4.4.1, added P-
   expanded IANA Considerations - Section 6

version 03 -> 04
   Many changes to bring into sync with RFC 5483




Bradner, Conroy & Fujiwara                                     [Page 22]


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