Technical and Operational Requirements for an ENUM Tier

Document Sample
Technical and Operational Requirements for an ENUM Tier Powered By Docstoc
					                                                                                                          V-08.00001-2005
                                                                                                              June 9, 2005



                                                                                                          CC1 ENUM LLC
                                                                                      Technical Advisory Committee




                             CC1 ENUM Tier 1B Registry
                       Technical and Operational Requirements
                     for a Specific Country within Country Code 1




CC1 ENUM LLC TAC
Approved Month DD, YYYY


Abstract
This document contains technical and operational requirements for operating an ENUM Tier 1 for Country Code 1. This includes
interfaces to other entities providing services for ENUM as well as the requirements for deploying and operating the ENUM Tier 1
infrastructure.
Tier 1B Technical and Operational Requirements                                  CC1 ENUM LLC TAC-08.00001-2005



FOREWORD
At the time it approved this document, the CC1 ENUM LLC TAC which had the following members:


                                             Jim Baskin   TAC Chairman, Verizon
                                               Tim Ruiz   GoDaddy.com
                                        Steven D. Lind     AT&T
                                              Bernie Ku   SBC Labs
                                      Mark McFadden       BT Americas
                                          Jay Carpenter   1-800 AFTA
                                      Phyllis Anderson    SBC Labs
                                      Richard Shockey     NeuStar
                                       Karen Mulberry     MCI
                                        Robert Schafer    MCI
                                         Ken Buchanan     BellSouth
                                            Penn Pfautz   AT&T
                                        Beth O'Donnell    COX
                                   Judith Oppenheimer     ICB
                                            Kaj Tiesink   Telcordia
                                            Tim Denton    CIRA
                                             Jim Danda    Sprint
                                         Alan Johnston    MCI
                                              Mir Islam   Sprint
                                    Kevin McCandless      Verisign




                                                              ii
Tier 1B Technical and Operational Requirements                                                      CC1 ENUM LLC TAC-08.00001-2005


Table of Contents
Section 1.0 Scope, Purpose, and Application ........................................................................................ 1
   1.1        Scope .......................................................................................................................................... 1
   1.2        Purpose ...................................................................................................................................... 1
   1.3        Application ............................................................................................................................... 1
Section 2.0 References ............................................................................................................................ 1
Section 3.0 Definitions, Acronyms, & Abbreviations .......................................................................... 3
   3.1        Definitions ................................................................................................................................ 3
   3.2        Acronyms & Abbreviations .................................................................................................... 5
Section 4.0              Introduction ................................................................................................................... 6
Section 5.0              Operational & Infrastructure Requirements ............................................................. 8
   5.1        Registry Database ................................................................................................................... 9
   5.2        Shared Registration System (SRS) ........................................................................................ 9
   5.3        Thick Registry Model .............................................................................................................. 9
   5.3        Zone Data................................................................................................................................ 10
   5.4        ContactInfo ............................................................................................................................. 10
   5.5        Security .................................................................................................................................... 16
   5.5.1         Operational System Security ........................................................................................... 16
   5.5.2         DNS Security (Editor’s Note: highlighted text below needs to be reviewed) ........... 17
   5.5.3         Protocol Security ............................................................................................................... 17
   5.5.4         Physical Security ............................................................................................................... 18
   5.5.5         Network Security ............................................................................................................... 18
   5.5.6         Backup Security.................................................................................................................. 19
   5.5.7         Security Audit and Reporting .......................................................................................... 19
   5.6        Customer Service Personnel Access Relevance ................................................................. 20
   5.7        Caching Requirements ........................................................................................................... 20
   5.8        System Turn-Up and Testing ............................................................................................... 20
   5.10       Operations and Maintenance............................................................................................... 20
   5.11       System Outage Prevention and Recovery .......................................................................... 21
   5.11.1        System Recovery Procedures ............................................................................................ 21
   5.11.2        Database Escrow and Backup ......................................................................................... 21
   5.12       Technical and Other Support ............................................................................................... 22

                                                                             iii
Tier 1B Technical and Operational Requirements                                                CC1 ENUM LLC TAC-08.00001-2005


  5.13        Other Responsibilities of the Tier 1B Registry ............................................................. 22
  5.14     Transition................................................................................................................................ 22
  5.15     Accommodation of Future Internet Architectural Enhancements ................................. 22
Section 6.0           Service Level Requirements (SLR) ........................................................................... 23
  6.1      Performance Specifications .................................................................................................. 23
  6.2      Service Availability ............................................................................................................... 23
  6.3      Service Availability - SRS .................................................................................................... 23
  6.4      Planned Outage ...................................................................................................................... 24
  6.5      Extended Planned Outage..................................................................................................... 25
  6.6      Processing Time...................................................................................................................... 25
  6.7      Cross-Network Nameserver Performance Requirements ................................................ 27
  6.8      Responsibilities of the Parties ............................................................................................. 28
  6.9      Connectivity (with Service Providers) ............................................................................... 28
  6.10     Performance and Capacity ................................................................................................... 28
  6.10     ENUM Tier 1B Registry Performance Specifications ....................................................... 29
  6.11     ENUM Tier 1B Registry Management ................................................................................ 31
  6.11.1      Reports and Files ............................................................................................................... 31
Section 7.0 Registry-Registrar Interface Requirements.................................................................... 32
  7.1      Shared Registration System (SRS) ...................................................................................... 32
  7.2      Interfaces between ENUM Tier 1A Registry and Tier 1B Registry ................................ 34
  7.3      Interfaces between ENUM Tier 1B and ENUM Registrars.............................................. 34
  7.4      Interfaces between ENUM Tier 1B and Tier 2 Registries ................................................. 34
Section 8.0       Provisioning ..................................................................................................................... 34
  8.1      Assumptions ........................................................................................................................... 35
  8.2      Provisioning Requirements .................................................................................................. 36
  8.3      Provisioning Procedures ....................................................................................................... 37
  Data Elements for ENUM Registration.......................................................................................... 75




                                                                        iv
Tier 1B Technical and Operational Requirements                                             CC1 ENUM LLC TAC-08.00001-2005



TABLE OF FIGURES
Figure 1 - ENUM Functional Architecture ............................................................................................ 6
Figure 2 – ENUM Registrant Selects Tier 2 Provider at Initial ENUM Registration ..........................
Figure 3 – ENUM Registrant did not select Tier 2 Provider at Initial ENUM Registration ...............
Figure 4 – ENUM Registrant Transfers ENUM Registration to another Registrar ............................
Figure 5 – ENUM Registrant Checks/Changes Information at ENUM Registrar ...............................
Figure 6 – ENUM Registrant Checks/Changes Information at Tier 2 Provider ..................................
Figure 7 – ENUM Registrar Checks/Changes Information at Tier 1B Registry ..................................
Figure 8 – ENUM Registrant Renews ENUM Registration....................................................................
Figure 9 – ENUM Registrant Terminates ENUM Registration .............................................................
Figure 10 – ENUM Registrant No Longer a TN Assignee ......................................................................




TABLE OF TABLES
Acronyms & Abbreviations ..................................................................................................................... 4
Table 2 - Recommended Zone Contact Data Elements ...........................................................................
Table 3 - Here are the recommended Registrar Contact Data Elements ..............................................




                                                                       v
                                                                              CC1 ENUM LLC TAC-07.00001-2005



                                      CC1 ENUM Tier 1B Registry
                       Technical and Operational Requirements
                     for a Specific Country within Country Code 1

1    SECTION 1.0             SCOPE, PURPOSE, AND APPLICATION
2
3    1.1     Scope
4    This document describes the ENUM Tier 1B technical and operational requirements for a specific country within
5    the North American Numbering Plan (NANP) Country Code 1 serving area. In particular these technical
6    requirements are to be used to select the ENUM Tier 1B Registry for US telephone numbers (TNs) under the
7    ITU-T E.164 international numbering standard, and may be accepted or modified by other NANP member nations
8    when determining their approach.
 9   The Tier 1B Registry operator is the single entity responsible for providing ENUM Registry services for US TNs,
10   including management of pointers to Tier 2 Provider nameservers. The Tier 1B Registry does not handle Naming
11   Authority Pointer (NAPTR) records but points at Tier 2 Providers where NAPTR records associated with E.164
12   numbers are stored. The ENUM Tier 1B Registry must establish an open standard interface which is available for
13   all ENUM Registrars to use.
14
15   1.2     Purpose
16   This document is intended to provide the specifications necessary to implement the ENUM Tier 1B Registry
17   components for Numbering Plan Area (NPA) resources within the U.S. It is intended to provide sufficient
18   information to allow a contracting entity to issue an RFP for an ENUM Tier 1B Registry implementation. As
19   such, it describes, among other things, the reference architecture for the ENUM Tier 1B Registry.. It also provides
20   the critical security and privacy requirements for implementing this system for the US numbering space.
21   This document will be distributed to all stakeholders with a view of seeking consensus amongst an audience that
22   is as large as possible, with a view of ensuring that the implementation of a country’s ENUM Tier 1B Registry
23   proceed as swiftly and as smoothly as possible.
24
25   1.3     Application
26   This document is intended to be used as the basis for an RFP that will identify and provide the technical
27   specifications necessary to select a vendor that will implement the ENUM Tier 1B Registry components for NPA
28   resources within the U.S. This may also be used by other countries within the NANP for their ENUM Tier 1B
29   registry vendor selection requirement.
30

31   SECTION 2.0 REFERENCES
32   The following references contain provisions which, through reference in this text, constitute provisions of this
33   technical requirement. At the time of publication, the editions indicated were valid. All documents are subject to
34   revision, and parties to agreements based on this specification are encouraged to investigate the possibility of
35   applying the most recent editions of the references indicated below.

                                                             1
     Tier 1B Technical and Operational Requirements                   CC1 ENUM LLC TAC-08.00001-2005


36   EDITORS NOTE – MAY NEED TO ARRANGE IN ALPHABETICAL ORDER
37   [1] Falstrom, P., Mealling, M., “The E.164 to Uniform Resource Identifiers (URI)
38      Dynamic Delegation Discovery System (DDDS) Application (ENUM)”, RFC 3761, April 2004.
39   [2] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
40   [3] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822,
41              August 1982.
42   [4] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
43   [5] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC 954, October 1985.
44   [6] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
45   [7] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035,
46              November 1987.
47   [8] Mockapetris, P., "DNS encoding of network names and other types", RFC 1101, April 1989.
48   [9] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
49   [10] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection and Operation of Secondary DNS Servers",
50              BCP 16, RFC 2182, July 1997.
51   [11] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
52   [12] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-ADDR.ARPA delegation", BCP 20, RFC 2317,
53              March 1998.
54   [13] Hollenbeck, S., "Extensible Provisioning Protocol", RFC 3730, March 2004           .
55   [14] Hollenbeck, S., "Extensible Provisioning Protocol Domain Name Mapping", RFC 3731, March 2004.
56   [15] Hollenbeck, S., "Extensible Provisioning Protocol Host Mapping", RFC 3732, March 2004.
57   [16] Hollenbeck, S., "Extensible Provisioning Protocol Contact Mapping", RFC 3733, March 2004.
58   [17] Hollenbeck, S., "Extensible Provisioning Protocol Transport Over TCP", RFC 3734, March 2004.
59   [18] Crispin, M., “Internet Message Access Protocol, Version 4rev1”, RFC 3501, March 2003.
60   [19] Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment
61              Procedures”, RFC 3405, October, 2002
62   [20] Ohta, M., “Incremental Zone Transfer in DNS (IXFR).” RFC 1995, August 1996
63   [21] Vixie, A P., “Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY).” RFC 1996,
64              August 1996
65   [22] Vixie, A P., Ed., S. Thomson, Y. Rekhter, and J. Bound “Dynamic Updates in the Domain Name
66               System (DNS UPDATE).” RFC 2136, April 1997
67   [23] Vixie, P., “Extension Mechanisms for DNS (EDNS0).” RFC 2671, August 1999
68   [24] Crawford, M. and C. Huitema, “DNS Extensions to Support IPv6 Address Aggregation and
69              Renumbering.” RFC 2874, July 2000
70   [25] Eastlake, D., “DNS Request and Transaction Signatures (TSIG(0)s).” RFC 2931, September 2000
71   [26] R. Bush, D. Karrenberg, M. Kosters, & R. Plzak, “Root Name Server Operational Requirements,”
72             RFC2870, June 2000.
73   [27] M. Horowitz & S. Lunt, “FTP Security Extensions” RFC 2228, October 1997.
74   [28] M. Allman & S. Ostermann, “FTP Security Considerations,” RFC 2577, May 1999.
75    [29] ENUM Forum Final Specifications Document "ENUM Forum Specifications for US
76   Implementation    of ENUM Document" 6000_1_0, March 14, 2003
77




                                                        2
     Tier 1B Technical and Operational Requirements                         CC1 ENUM LLC TAC-08.00001-2005


78   SECTION 3.0 DEFINITIONS, ACRONYMS, & ABBREVIATIONS
79
80   3.1    Definitions
             CNNP Test:           The measurements will be conducted by sending strings of DNS
                                  request packets from each of four measuring locations to each of
                                  the .NET nameservers and observing the responses from the
                                  .NET nameservers. (These strings of requests and responses are
                                  referred to as a "CNNP Test".)
             DNS:                 the Internet domain-name system
             Dynamic          Used to implement lazy binding of strings to data, in order to support
             Delegation       dynamically configured delegation systems such as ENUM is based
             Discovery System on. The DDDS functions by mapping some unique string to data
             (DDDS):          stored within a DDDS Database by iteratively applying string
                              transformation rules until a terminal condition is reached. (RFC 3401
                              to 3405)
             ENUM:                refers to a protocol developed in the Internet Engineering Task Force
                                  (IETF) (RFC 3761) whereby the Domain Name System (DNS) can be
                                  used for identifying available services associated with one E.164
                                  number
             ENUM Applicant:      Person/organization that is seeking to register an E.164 number into
                                  the CC1 ENUM Tier 1B Registry
             ENUM Domain:         E.164 Number in domain format as it is registered in the “e164.arpa”
                                  domain.
             ENUM Registrar:      Entity that will provide ENUM registration services to ENUM
                                  Applicant
             ENUM Registrant:     Person/organization that has registered their E.164 number into the
                                  CC1 ENUM Tier 1B Registry
             ENUM Tier 1A Organization that registers ENUM domains corresponding to NPAs
             Registry:    and hosts the set of their authoritative NS records.
             ENUM Tier 1B Organization that registers ENUM domains corresponding to E.164
             Registry:    numbers and hosts the set of pointers to their Tier 2 name servers
             Personal Data:       data about any identified or identifiable person or entity
             Registry Data:       all Registry Database data maintained in electronic form, and shall
                                  include Zone-File Data, all data used to provide Registry Services
                                  submitted by ENUM Registrars in electronic form, and all other data
                                  used to provide Registry Services concerning particular domain name
                                  registrations or nameservers maintained in electronic form in the
                                  Registry Database.

81

             Registry Database:   a database comprised of data about one or more DNS domain names

                                                            3
Tier 1B Technical and Operational Requirements                       CC1 ENUM LLC TAC-08.00001-2005


                             within the domain of the Registry that is used to generate either DNS
                             resource records that are published authoritatively or responses to
                             domain-name availability lookup requests or ContactInfo queries, for
                             some or all of those names
        Tier 2 Provider:     Person/organization that maintains the E.164 number NAPTR records
                             for specific communication services.

        Registry Model - A thick registry is one in which all of the information associated with
        Thick            registered entities, including both technical information (information
                         needed to produce zone files) and social information (information
                         needed to implement operational, business, or legal practices), is
                         stored within a central registry repository.
        Registry Model - In the thin model, only domain and name server information is stored
        Thin             within the registry; contact information is stored at each registrar. As a
                         result, each registrar must operate its own server in order to provide
                         access to this information.
        Core Internet    Is an extraordinary and identifiable event beyond the control of
        Service Failure
                             Registry Operator affecting the Internet services to be measured
                             pursuant to SLR’s. Such events include but are not limited to
                             congestion, collapse, partitioning, power grid failures, and
                             routing failures.
        Core Services        The three core services provided by the Registry - SRS,
                             Nameserver, and ContactInfo Services.
        Performance          The specific committed performance service levels as specified
        Specification
                             herein.
                             The Registry's rating system for Performance Specifications.
        Performance
        Specification        Some Performance Specifications are more critical to the
        Priority             operations of the Registry than others. Each of the Performance
                             Specifications is rated as C1-mission critical, C2-mission
                             important, C3- mission beneficial, or C4-mission maintenance.
        Registrar            Refers to all of the Accredited Registrars who have executed
        Community
                             Registry-Registrar Agreements with Registry Operator for the
                             Registry.
                             This refers to the nameserver function of the Registry and the
        Nameserver
                             nameservers that resolve DNS queries from Internet users. This
                             service is performed by multiple nameserver sites that host DNS
                             resource records. The customers of the nameserver service are
                             users of the Internet. The nameservers receive a DNS query,
                             resolve it to the appropriate address, and provide a response.

                                                      4
     Tier 1B Technical and Operational Requirements                                CC1 ENUM LLC TAC-08.00001-2005


             Performance          The specific committed performance service levels as specified in this
             Specifications       document. These Performance Specifications also set forth Registry
                                  Operator's obligations directly to the Tier 1B under the Registry
                                  Agreement.
             WHOIS                Refers to a domain name Registry's WHOIS service. Registries
                                  provide contact information related to registered domain names
                                  and nameserver through a WHOIS service. Any person with
                                  access to the Internet can query the Registry's WHOIS service
                                  directly (via the Registry website) or through a Registrar.
                                  (RFC3912)




82
83   3.2    Acronyms & Abbreviations
           AAA                Authentication, Authorization and Accounting
           ASCII              American Standard Code for Information Interchange
           ASP                Application Service Provider
           CC1                Country Code 1
           CC1 ENUM LLC       Country Code 1 ENUM Limited Liability Corporation
           CNAME              Canonical Name
           CNNP               Cross Network Name Server Performance
           CSR                Customer Service Representatives’
           DDDS               Dynamic Delegation Discovery System
           DNS                Domain Name System
           DNSSEC             DNS Security Extension
           ENUM               TElephone NUmber Mapping
           EPP                Extensible Provisioning Protocol
           FCC                Federal Communications Commission
           FQDN
           FTP                File Transfer Protocol
           HVAC               Heating, Ventilating, and Air Conditioning
           HTTP               Hypertext Transfer Protocol
           IAB                Internet Architecture Board
           ICANN              Internet Corporation for Assigned Names and Numbers
           IETF               Internet Engineering Task Force
           LDAP               Lightweight Directory Access Protocol
           IRIS
           ITU                International Telecommunications Union
           ITU-T              International Telecommunications Union – Telecommunications Sector
           LDAP               Lightweight Directory Access Protocol
           NANP               North American Numbering Plan
           NAPTR              Naming Authority Pointer (DNS Resource Record)
           NIC                Network Information Center


                                                                  5
     Tier 1B Technical and Operational Requirements                                   CC1 ENUM LLC TAC-08.00001-2005


            NPA                  Numbering Plan Area
            NS                   Name Server
            OAM&P
            PoP                  Point of Presence
            RFC                  Request for Comments
            RIPE NCC             Réseaux IP Européens Network Coordination Centre
            RTT                  Round-Trip Time
            SP                   Service Provider
            SRS                  Shared Registration System
            SSL                  Secure Socket Layer
            TCP                  Transmission Control Protocol
            TLS                  Transport Layer Security
            TN                   Telephone Number
            TSP                  Telephony Service Provider
            TSIG                 Transaction Signatures
            UDP                  User Datagram Protocol
            UTF-8                Unicode Transformation Format -8 encoding
            URI                  Uniform Resource Identifier
            URL                  Uniform Resource Locator
            US                   United States
            WWW                  World Wide Web



84   SECTION 4.0              INTRODUCTION
85   This section specifies the reference architecture of a single common ENUM DNS domain, 1.e164.arpa, within
86   Country Code 1.
87   ENUM implementation is based on a tiered architecture as shown in Figure 1. At Tier 0 is the RIPE NCC which
88   maintains the e164.arpa zone.1 Entries in the RIPE NCC nameservers correspond to country codes and point to
89   the name servers of the Tier 1 Registry that is the authoritative nameserver for that country code. Entries in Tier 1
90   Registries normally correspond to individual telephone numbers and point to the Tier 2 nameservers which hold
91   the NAPTR records used to provide actual communication services.
92   Because Country Code 1 corresponds to an integrated numbering plan in which the country code is shared among
93   several countries, the plan of the LLC is to split Tier 1 functionality into a Tier 1A, which would receive the CC1
94   delegation from the Tier 0, and potentially multiple Tier 1Bs serving different CC1 (NANP) member countries.
95   Entries in Tier 1 A will correspond to NPAs and will point to the Tier 1B that holds per –number delegations for
96   the numbers within the given NPA.



     1
         The instructions regarding operations            of   the       domain   e164.arpa   can   be   found   at   the   URL:
     http://www.ripe.net/rs/enum/instructions.html,
     The ITU-T TSB evaluates delegation requests. Information on how TSB will handle ENUM requests can be found under the
     bullet "Interim Procedures" at the ITU-T Web site at: http://www.itu.int/ITU-T/inr/enum/ .
     .



                                                                     6
      Tier 1B Technical and Operational Requirements                           CC1 ENUM LLC TAC-08.00001-2005


97    Tier 1 B Registries are required to deal directly with the CC1 ENUM Tier 1A Registry to arrange for the
98    provisioning of NS records for the NPAs they serve into the CC1 ENUM Tier 1A Registry.
 99   CC1 ENUM Tier1B registry(ies) will be required to establish a business relationship with the CC1 ENUM Tier
100   1A Registry prior to registering any NPA in e164.arpa. The nature of the business relationship will be defined by
101   the contracting entity, embodied in a Registry agreement, and will be the same for all CC1 ENUM Tier1B
102   registry(ies). This is necessary to ensure that each CC1 ENUM Tier1B registry’s records are properly maintained
103   and that only the assignee of the NPA which has been designated to participate in ENUM by the national
104   administration in charge of the NPA in question can register it into Tier 1A.
105   ENUM Registrars, the entities that accept registration requests from number assignees, will, in turn, be required to
106   establish a business relationship with the CC1 ENUM Tier1B registry(ies) prior to registering any telephone
107   number, in e164.arpa.
108   The nature of the business relationship between the Tier 1B and the ENUM registrars will be defined by the
109   contracting entity, embodied in a Registry agreement, and will be the same for all ENUM Registrars for a given
110   NPA entered into Tier 1A. This is necessary to ensure competitive equity between registrars in Tier1B and to
111   ensure that ENUM Registrant’s records are properly maintained and that the assignee of the E.164 telephone
112   number has decided to participate in ENUM.
113
114




                                                               7
      Tier 1B Technical and Operational Requirements                          CC1 ENUM LLC TAC-08.00001-2005




                                                                                       “.”           and
           International                                                    Root       .arpa



                                                                                       e164.arpa
                                                                           Tier 0



           Country Code 1                                                              1.e164.arpa
                                                                          Tier 1A
                                               NPA Data



           Individual                       Authentication &
                                           Validation Entities
           E.164 zone(s)



                                                                                       a.p.n.1.e164.arpa
                                                                           Tier 1B
                        Registrant              Registrar
                                                                          Registry




                                                                           Tier 2
                                                                          Provider




                                                                 Application Service Provider

115
116                                  Figure 1 - ENUM Functional Architecture
117   The Tier 2 Provider for an E.164 number maintains the actual NAPTR records that contain URI’s (Uniform
118   Resource Identifiers) for specific communication services, and the Application Service Provider (ASP) uses these
119   records to provide those services to the number assignee (Registrant)
120

121   SECTION 5.0              OPERATIONAL & INFRASTRUCTURE REQUIREMENTS
122   This section provides requirements for the operation and infrastructure of the ENUM Tier 1B registry.
123   Service Level Requirements are contained in Section 6.0.

                                                             8
      Tier 1B Technical and Operational Requirements                            CC1 ENUM LLC TAC-08.00001-2005


124
125
126   5.1       Registry Database
127   The Registry database is the central repository for all objects concerning ENUM domain name registrations in an
128   ENUM Tier 1B Registry. The three primary objects associated with an ENUM Tier 1B registration are: domain,
129   host and contact. It is critical that a Registry database operate in a responsive and robust manner.
130   An ENUM Tier 1B Registry should describe how it would meet the following requirements for an ENUM
131   Registry database, and it should provide estimates of demand if necessary.
132   A Registry database:
133            Shall be sized to accommodate the expected demand at initial launch, and to support growth without
134             interruption as ENUM matures.
135            Shall be able to perform transactions at a rate that meets the needs of the ENUM users.
136            Shall maintain its performance based on agreed to service-level measurements, even as the number of
137             users, workload volume, or database size increases.
138            Shall maintain a high level of availability as required by SLR’s contained herein. ENUM Tier 1B
139             Registry candidate should describe what level of availability it believes is necessary; what amount of
140             scheduled maintenance is necessary; and how it would expect to meet the appropriate availability level.
141            Shall be replicated and hosted in geographically dispersed data centers to achieve high availability and
142             facilitate data backup and recovery.
143
144   5.2       Shared Registration System (SRS)
145   An ENUM Tier 1B Registry will maintain the addresses of the nameservers of the Tier 2 providers in the US
146   ENUM name space and will have authority to communicate with the ENUM Tier 1A Registry.
147   An ENUM Tier 1B Registry is required to:
148             Allow concurrent operations from multiple ENUM Registrars.
149            Provide non-discriminatory services to each authorized ENUM Registrar to perform registration related
150             operations
151            Provide and conduct non-discriminatory registrar certification procedures
152            Support open standard interfaces between the ENUM Tier 1B Registry and authorized ENUM Registrars
153            Support the “thick registry” model whereby contact information about ENUM domain name registrations
154             (ENUM Registrant, administrative, technical, etc.) is centrally stored.
155            Perform Zone data creation and maintenance necessary to update the zone data and information in the
156             local data stores
157            Support open standard interface(s)
158
159   5.3       Thick Registry Model
160
161   A thick registry is one in which all of the information associated with registered entities, including both technical
162   information (information needed to produce zone files) and social information (information needed to implement
163   operational, business, or legal practices), is stored within a central registry repository.
164
165   The Thick Registry will provide for centralized escrow transfers and lawful access. It will also provide
166   a source for all ContactInfo queries.
167
168                    Escrow – transfers – lawful access
                                                                9
      Tier 1B Technical and Operational Requirements                               CC1 ENUM LLC TAC-08.00001-2005


169                    Contact Info Single Source for all quires
170
171        The thick domain registry model -- helps take care of escrow concerns.
172                When a registrar goes out of business or experiences some other kind of disaster that removes its data
173                 store, the data kept at the thick Tier 1B registry can help transfer registrations to a different registrar,
174                 and help registrants keep their domain names. Besides that, keeping registrant information at the Tier
175                 1B registry helps registry operators enforce the new transfer’s policy, and may generally contribute to
176                 making the transfer’s process run more smoothly.
177   the thick model often involves transfer of registrant data (both the identifying information, and the sensitive
178   information that is constituted by the link between a domain name and the registrant's identifying information)
179   across jurisdictional boundaries that may separate very different privacy regimes. This concern should weigh even
180   heavier when the registry is not just keeping the thick data set, but actually uses these data for making its own
181   WHOIS service available to the public at large.
182
183   5.3       Zone Data
184   Zone data is typically a database file (or a collection of database files) consisting of the technical information that
185   the DNS requires to function correctly. Zone data generation is the term traditionally used to describe the process
186   of generating zone information from the Registry database, deploying it to the primary server, and then
187   propagating it out to the secondary servers. The latter two steps are also called zone data propagation.
188   An ENUM Tier 1B Registry candidate should describe how it would meet the following requirements for zone
189   data operations:
190            The SRS/Registry Database shall provide means to generate the zone data from the Registry database to
191             reflect changes through the ENUM Registry-ENUM Registrar interface as defined in the Service Level
192             Requirements (SLRs). .
193            The zone data, once generated by SRS/Registry Database, shall be reliably and securely propagated to all
194             ENUM Tier 1B nameservers with minimum delay.
195            The frequency of zone data generation and the delay of zone data propagation shall meet the SLR
196             requirements
197            Zone data generation and propagation procedures shall be carefully engineered so that they will not
198             adversely affect the normal ENUM Tier 1B Registry and nameservers operations.
199            Zone data distribution procedure should conform to appropriate IETF standards.
200            The ENUM Registrar to ENUM Tier 1B Registry SRS shall be the only automatic means by which an
201             ENUM Registrar can make changes to the ENUM domain names it sponsors without the need for
202             Registry personnel intervention.
203            The nameservers for an ENUM Tier 1B Registry shall be placed in geographically dispersed data centers
204             on separate network facilities to allow for maximum redundancy against disaster and failures.
205            The registry database shall support logging and backup capabilities for all zone data updates.
206
207   5.4       ContactInfo
208   Instead of a conventional WHOIS service, a new query service known as ContactInfo will be provided for
209   ENUM. This service will provide a means of contacting the necessary entities for trouble resolution without
210   compromising the privacy of the ENUM Registrant. It will also allow for appropriate disclosure of ENUM
211   Registrant information in alleged cases of fraudulent or illegal activity on the part of a ENUM Registrant. An
212   ENUM Tier 1B Registry candidate is required to describe how they would provide this service to meet the needs
213   of the communications industry and the public while safeguarding the personal information of the ENUM
214   Registrants.

                                                                  10
      Tier 1B Technical and Operational Requirements                           CC1 ENUM LLC TAC-08.00001-2005


215
216   The Tier 1B will respond to all lawful requests from appropriate authorities.
217
218   Editor’s Note: Add May 4th Contact Info document here – See Below.
219   5.4.1   Introduction
220   This section describes specific requirements for the Tier 1B operator to maintain a ‘ContactInfo’
221   database. Also included in this section are the following: how the database should be operated, and
222   what information should be publicly accessible.
223
224   5.4.2   Need for ContactInfo Databases
225       1. There is a need for the Tier 1B Operator to maintain ContactInfo databases associated with
226          ENUM registrations.
227       2. The appropriate technology for maintaining public access to such ContactInfo should be the
228          IETF IRIS protocol developed by the CRISP working group with ENUM extensions, assuming
229          the appropriate documents attain RFC status.
230       3. There is a requirement on the TIER 1B operator to maintain such a database in a manner known
231          as the “Thick Registry” where the TIER 1B Registry operator maintains the authoritative
232          database of registration information obtained from all Registrars.
233       4. The information from that database that could be made publicly accessible is a matter of policy
234          for the CC1 ENUM LLC to determine.
235
236   5.4.3   Background
237   In the domain name registration industry, access to Contact-Info has typically been preformed using
238   what is known as the WHOIS service. On the Internet, the term "Whois" is often taken to mean the
239   meta-data about a registered resource, most often a domain name. This generalization of the term has
240   its roots in the protocol originally specified by RFC 812, titled "Nicname/Whois".
241
242   The original intent of this protocol was to describe a centralized database running at the Network
243   Information Center (NIC). At the time of this development, the Internet was a much different type of
244   network than it is today. In those days, the Internet was a connection of heterogeneous networks glued
245   together by the Internet. Administrators of the Internet nodes were all trusted, and the NIC was a
246   central administration point of the Internet.
247
248   In order to maintain parity within the ongoing and evolving structure of the Internet, the Internet
249   Engineering Task Force (IETF) chartered the Cross-Registry Internet Service Protocol (CRISP) Working
250   Group. The intent is to replace the aging Nicname/Whois protocol with the Internet Registry
251   Information Service (IRIS) protocol (now published as RFC 3981, RFC 3982, and RFC 3983).
252
253   As the number of end users for this type of directory service has increased, so have the types of data
254   associated with federated Internet resources. The combined list of contact types from RFC 3982 and


                                                              11
      Tier 1B Technical and Operational Requirements                       CC1 ENUM LLC TAC-08.00001-2005


255   draft-ietf-crisp-iris-areg-10.txt consists of 8 defined types: the registrant, billing contacts, technical
256   contacts, administrative contacts, legal contacts, zone contacts, abuse contacts, and security contacts.
257
258   In recognition that there is both a need and potentially a requirement for authoritative databases
259   associated with E.164 numbers in the context of various national implementations the IETF ENUM
260   working group is currently developing a version of the IRIS protocol specifically for ENUM national
261   administrations.
262
263   http://www.ietf.org/internet-drafts/draft-ietf-enum-iris-ereg-00.txt
264
265   5.4.4   General ContactInfo Requirements
266   The general requirements for the ContactInfo database are:
267      1. Mining Prevention: providing some technical means to guard against massive mining of the
268          information base
269      2. Minimal Technical Reinvention: reuse existing technologies to promote standing up of a service
270          and create client software that will use it
271      3. Standard and Extensible Schemas
272      4. Level of access: not all data need be equally accessible by all users of the service
273      5. Client processing: facilitating the creation of client software that can automatically extract
274          relevant details from the services responses
275      6. Optional Decentralization: the protocol must not require that all data be aggregated in some
276          central repository in order to provide service
277      7. Authentication Distribution: the protocol itself must not require individual service operators to
278          participate in a single standard authentication system
279      8. Lookups: the protocol must allow a nameserver lookup given a fully qualified host name or IP
280          address of a name server
281      9. Searches: the protocol must allow searches by either exact name or partial name match with the
282          ability to narrow the search to registrants to a particular FQDN.
283      10. Result Set Limits: the protocol must include provisions for allowing a server operator to express
284          a client search limit
285      11. Internationalization
286
287   ContactInfo Databases must be policy neutral
288           a.   Access can be anonymous and or authenticated
289           b.   Data can be given to some users and/or not to others
290           c.   Trust can be based locally regionally, globally or all of the above
291           d.   Information can be centralized distributed or centrally indexed but distributed or all of the
292                above
293
294   Contact-Info Databases should use modern Authentication and Authorizations methods
295           a. Authentication: passwords, one time passwords, digital certificates, references



                                                           12
      Tier 1B Technical and Operational Requirements                      CC1 ENUM LLC TAC-08.00001-2005


296           b. Authorization: user based, sequence based, chain based, attribute based, time based, refer
297           based.
298
299   5.4.5   Data Collection Requirements and ContactInfo Data Access
300   The Tier 1B operator will ultimately accredit various entities to perform the function of ENUM
301   Registrars. Those Registrars will as part of the registration process collect a variety of data associated
302   with ENUM registrations which may include the registrant, billing contacts, technical contacts,
303   administrative contacts, legal contacts, zone contacts, abuse contacts, and security contacts. The data
304   that can be collected will ultimately be determined by the ENUM LLC as a matter of policy.
305
306   ENUM accredited Registrars will ultimately transmit copies of specified data for each registration to
307   the Tier 1B operator for maintenance under the concept of a “thick Registry”.
308
309   The Tier 1B operator will then take portions of the data; such as Registrar contact data and populate an
310   IRIS database with that information for public access. What data is to be publicly accessible is a matter
311   of policy to be determined by the CC1 ENUM LLC.
312
313   Below, are the recommended data elements that should be included in the Zone ContactInfo. This
314   information is pertinent to the Tier II that stores the actual NAPTR records. The data elements that are
315   marked as public must be made available to all queries and it is recommended that this data be true
316   and accurate. The use of proxied data is strongly discouraged.
317
318   Table 2 - Here are the Recommended Zone Contact Data Elements:
      Data Element                         Private     Public      Example

      Domain Name                                      X           4.5.6.7.5.5.5.3.2.1.1.e164.arpa

      Domain ID                                        X

      Domain Status                                    X           REGISTRAR-LOCK

      Domain Updated Date                              X

      Domain Expiration Date                           X

      Registrar Name                                   X

      Registrar URL                                    X

      Last Updated by Registrar                        X

      Last Transferred                                 X

      Name Server ID                                   X


                                                           13
      Tier 1B Technical and Operational Requirements                        CC1 ENUM LLC TAC-08.00001-2005


      Name Server Name                                  X             BAY-W2.ACME.FOO

      Name Server URL                                   X             Iris:ereg1//t1b.us/host/bay-
                                                                      w2.acme.foo

      Name Server Status                                X

      Name Server Association Status                    X

      Name Server IP Address                            X

      Name Server Creation Date                         X

      Name Server Last Transfer Date                    X

      Name Server Authorization                         X
      Information

      Tier 1B Name                                      X

      Tier 1B URL                                       X

      Tier 1B Name Server Name                          X

319
320    Below, are the recommended data elements that should be included in the Registrar ContactInfo. The
321   data elements that are marked as public must be made available to all queries and it is recommended
322   that this data be true and accurate. The use of proxied data is strongly discouraged. The data elements
323   that are marked as private must be secured in the ContactInfo database and only available to queries
324   that have the appropriate authorization. The registrant has the right to change the default data
325   elements that are marked as private to public at their discretion. If a data element is marked optional,
326   then there is no requirement for populating those fields.
327
328   Table 3 - Here are the recommended Registrar Contact Data Elements
      Data Element                            Private        Public       Example

      Registrar Name                                         X

      Registrar Address                                      X

      Registrar Phone Number                                 X

      Registrar URL                                          X

      Registrar Admin. Contact Name                          X

      Registrar Admin Contact Phone                          X
      Number

      Registrar Admin Contact Email                          X


                                                            14
      Tier 1B Technical and Operational Requirements                  CC1 ENUM LLC TAC-08.00001-2005


      Admin Contact Name                     X

      Admin Contact Phone Number             X

      Admin Contact Email                    X

      Billing Contact Name                   X

      Billing Contact Phone Number           X

      Billing Contact Email                  X

      Technical Contact Name                 X

      Technical Contact Phone Number         X

      Technical Contact Email                X

      Registrant Name                        X

      Registrant Company Name                X

      Registrant Address                     X

      Registrant Contact Phone Number        X

      Registrant Contact Email               X

      Legal Contact Name (Optional)          X

      Legal Contact Phone Number             X
      (Optional

      Legal Contact Email (Optional)         X

      Abuse Contact Name (Optional)          X

      Abuse Contact Phone Number             X
      (Optional)

      Abuse Contact Email (Optional)         X

      Security Contact Name (Optional)       X

      Security Contact Phone Number          X
      (Optional)

      Security Contact Email (Optional)      X

329
330   5.4.6   Privacy Considerations
331   ENUM Registrars and registries will comply with applicable regulations on the collection of personally
332   identifying information and disclose the reasons for the collection and publication of such data.

                                                        15
      Tier 1B Technical and Operational Requirements                           CC1 ENUM LLC TAC-08.00001-2005


333
334   Even though the ENUM Registry will maintain a full and complete copy of all relevant data associated
335   with ENUM registrations in accordance with the requirement for a “thick Registry”, it is anticipated
336   that Registrars will handle normal and routine inquiries about registrants. The Registry operator will
337   refer such inquires to the appropriate Registrar.
338
339   It is anticipated that personally identifying registrant information associated with ENUM would not be
340   made publicly available through the ENUM ContactInfo system, however such data could be made
341   available to authorized entities (such as Law Enforcement agencies) under appropriate authentication
342   and authorization procedures.
343
344   Many individuals, businesses or institutions may, however, may choose to have personally identifying
345   information exposed in the ContactInfo system. The Registry-Registrar interface SHOULD be able to
346   flag appropriate fields for the Registry to publish in a separate registrant info field.
347
348   In certain special cases where the registrant chooses to manage its own DNS infrastructure the
349   registrant may also be the zone contact. Under these circumstances the requirement for publishing zone
350   contact data may override personal privacy considerations. In those cases the registrant will be fully
351   informed via an appropriate disclosure of the circumstances and necessity to publish such data.
352
353   5.4.7   Recommendation
354   It is recommended that, Registrar contact, zone contact and zone administration contact data always be
355   made publicly available and, optionally registrant information data at the explicit request of the
356   registrant.
357
358   5.4.8   Escrow Requirement
359   An escrow agreement for all Registry-Registrar data contained within the ContactInfo database
360   between the Tier 1B Registry operator, an appropriate escrow service provider, and the CC1
361   ENUMLLC will be is essential to ensure business continuity and stability of the 1.e164.arpa service.
362
363   5.5   Security (Editor’s Note: Need to align section with Tier1A-ALL - Action Item need review Tier
364   1A and Tier 1B text to determine what should be retained in the section below)
365   A Tier 1B must secure both Registry operations and data. A Registry shall conduct comprehensive threat
366   analyses on all parts of the Registry system to identify the vulnerable points and the types of security attacks.
367   Based on the analyses, the Registry shall define and implement multi-tiered procedures that provide security
368   protections to all parts of the Registry system
369
370   5.5.1   Operational System Security
371   ENUM Tier 1B Registries, SRS and nameserver data centers are subject to a wide range of security threats,
372   including hacking, break-ins, data tampering, denial of service, and physical attacks against the facility. Further,
373   because an ENUM Tier 1B Registry will contain proprietary data from ENUM Registrars and ENUM Registrants,
                                                              16
      Tier 1B Technical and Operational Requirements                           CC1 ENUM LLC TAC-08.00001-2005


374   security procedures must incorporate user authentication procedures that ensure that each ENUM Tier 1B
375   Registry’s files are available only to its own personnel. Failure to address these security threats creates the risks
376   of unplanned downtime and the disruption or denial of services.
377   An ENUM Tier 1B Registry candidate should describe how it intends to secure both Registry operations and data.
378   At a minimum, the description should include the following:
379          Protection/Prevention of compromise of the systems hosting or managing Tier 1B
380          Protection from Denial of Service attacks (internal & external)
381          Requirements for maintaining security updates for all software
382          Security (integrity, authenticity) of communications between the components of the Tier 1A and
383           1B service (name servers, registry, etc)
384          Encryption requirements
385          Authentication & Authorization requirements
386          Requirements on ISPs providing connectivity for Tier 1B
387
388   5.5.2 DNS Security (Editor’s Note: highlighted text below needs to be reviewed)
389   As this system is built on top of DNS, one can not be sure that the information one gets back from DNS
390   is more secure than any other DNS query. Being the only extant mechanism for securing DNS
391   responses, DNSSEC is the obvious solution for ensuring the security of ENUM responses. However, at
392   the time of publication of this document the DNSSEC standard has not been finished. Until that time
393   ENUM's use of DNSSEC is merely recommended. Once DNSSEC is published as a Proposed Standard,
394   ENUM based systems SHOULD fully implement DNSSEC. At the point at which DNSSEC becomes a
395   Draft Standard, it MUST be implemented by ENUM compliant systems.
396   Additionally, due to the fact that some parts of the ENUM system may be using DNSSEC before others,
397   resolvers MUST be capable of handling responses containing DNSSEC-related RR types even in cases
398   where the resolver or client application is unwilling or unable to perform DNSSEC validation
399
400   The Tier 1B registry must be DNSSEC compliant when the IETF draft standard has been published.
401   Also the following DNS security requirements are required:
402          DNS servers will run a minimum set of applications and system services, in addition to the DNS server
403           software. Checks will take place on all DNS servers to ensure that data integrity is maintained.
404

405                                   6-9-05 TAC Review Ended Here.
406   5.5.3   Protocol Security
407          Security of the SRS applications shall be provided in part via the mandatory use of the TLS [RFC 2246]
408           protocol for transport layer security.
409          Each EPP session shall be authenticated and encrypted using TLS. The ENUM Registry shall authenticate
410           every EPP client connection using both an X.509 server certificate, issued by a commercial Certification
411           Authority identified by the ENUM Tier 1B Registry, and its ENUM password.




                                                               17
      Tier 1B Technical and Operational Requirements                            CC1 ENUM LLC TAC-08.00001-2005


412
413   5.5.4   Physical Security
414          The Tier 1B Registry shall employ a variety of physical security systems to ensure that unauthorized
415           personnel have no access to sensitive equipment and/or data.
416          All servers containing any sensitive data shall be physically secured so that only a controlled list of
417           people can obtain access.
418          The hosting centers s shall be secured so that no access to the internal networks is possible for
419           unauthorized persons. All internal networks shall be isolated from public access, and external Internet
420           links shall be firewall-protected to prevent intruders from gaining access.
421          Physical precautions inside the server rooms shall include movement detectors (using infra-red or similar
422           means) to alert security personnel should an intruder gain access to a secured location. Alarms will be
423           fitted to all doors and windows, which open into or out of a restricted area.
424          The doors and windows shall be secure enough to withstand a reasonable amount of force, and damage to
425           doors or windows shall also trigger the alarms.
426          Security staff shall be present at all times, and should have sufficient training to enable them to correct
427           most problems. Appropriate personnel shall also be contacted when necessary to help contain the
428           situation.
429          Access to the server room shall be controlled by a two-factor authentication system. An authorized
430           individual shall require both an authorized access token and a valid PIN or passcode to gain physical
431           access to the servers. Any use of an access token shall be logged and such logs shall be archived for at
432           least 1 year.
433           Should an access card be lost or stolen, it is the responsibility of each employee to report this in a timely
434           manner so that the lost card may be deactivated and a new card issued. Closed circuit TV shall be in place
435           at all sites for identification purposes should an unauthorized person attempt to use a stolen access card.
436           Personnel authorized temporary access to the servers, but not permanently issued access tokens shall be
437           escorted by permanent staff while within the restricted space.
438          24-hour access to the data center by authorized personnel shall not be hindered by aforesaid security
439           measures.
440
441   5.5.5   Network Security
442          User identification, passwords and IP range checking shall be required for all restricted services (which
443           includes services other than DNS resolution.).
444          Secure File Transfer Protocols shall be used for all "file transfers" between the ENUM Tier 1 Bs and the
445           Tier 1A Registry [RFC 2228, RFC 2577, or similar equivalent].
446          System maintenance shall be performed via SSL or similarly secured connections. Telnet servers shall not
447           be operational on any system on the DNS network due to their security risk.
448          Each system shall operate a very restricted set of basic services in the relevant sections for DNS,
449           ContactInfo, FTP, SCP and WWW services. Systems shall be firewall-protected in hardware, and IP
450           filtering rule sets shall be in place to reject packets that are not appropriate for a particular host.
451          DNS servers shall run a minimum set of applications and system services, in addition to the DNS server
452           software.
453          Checks shall take place on all DNS servers to ensure that data integrity is maintained.

                                                               18
      Tier 1B Technical and Operational Requirements                              CC1 ENUM LLC TAC-08.00001-2005


454          Services which are IP-restricted shall have each IP address specified individually. Network addresses are
455           not to be used, since this adds the risk that a host could masquerade as a spare IP address on an internal
456           network.
457          Packet "sniffers", designed to check all traffic passing through a network interface, shall be in place to
458           catch suspicious traffic. These will actively scan for incorrect or illegal packets, and alert the security
459           team. Packet sniffers may also give some indication of the source of an attack, which would be of use in
460           preventing that attack in the future.
461          Network security shall be verified by a security audit process, which involves scanning from an internet-
462           connected host all TCP and UDP ports on servers operated by the Tier 1B Registry.
463          Security tests shall be performed on the DNS Servers and a corresponding report audited on a regular
464           basis. Each test will attempt to take advantage of a security flaw using a specific attack method, and the
465           result shall be reported. Here is an non-exhaustive list of known attacks:
466               - Buffer overflow exploit
467               - Missing format string exploit
468               - Packet fragmentation attack
469               - Data flooding (SMURF ping, etc.)
470               - DNS spoofing
471               - FTP spoofing
472               - Dictionary passwords
473               - Replay attack
474               - Denial of service (DoS)
475   Some of these attacks may not be applicable to all services.
476   The Tier 1B Registry shall update the tests used when new vulnerabilities, security flaws, or techniques are
477   discovered. The updates shall be based on information from security-related mailing lists, websites, newsgroups,
478   and industry best practices.
479
480   The ENUM Tier 1B Registry shall update the tests used when new vulnerabilities, security flaws, or
481   techniques are discovered. The updates shall be based on information from security-related mailing
482   lists, websites, newsgroups, and industry best practices.
483
484   5.5.6   Backup Security
485          Backup shall be performed through a secure network on the main Tier 1B Registry site.
486          The Tier 1B Registry shall use an encryption scheme for the backup of sensitive data as a part of the
487           implementation process.
488          Backup information shall be stored in a secure off-site location.
489
490   5.5.7   Security Audit and Reporting
491   The Tier 1B Registry shall run a security audit on a regular basis but no less often than once per quarter.
492          The Tier 1B Registry shall run a security audit to test all systems for configuration issues and security
493           vulnerabilities. Results of this audit should then form the basis of a quarterly security auditreport, which
494           will also detail any recommendations for system alterations and a timeline for remediation.
495          All security breaches are to be reported to the Registry management responsible for security and to the
496           LLC. Should a serious breach be detected, some services may be suspended temporarily if this is

                                                               19
      Tier 1B Technical and Operational Requirements                           CC1 ENUM LLC TAC-08.00001-2005


497             necessary to ensure the reliability of the Tier 1B Registry data. [Note to LLC: bidders should detail
498             hierarchy of breach severity and escalation procedures.]
499            The Tier 1B Registry shall provide a monthly security status report to the CC1 ENUM LLC, including a
500             list of security incidents categorized by severity.
501
502   5.6       Customer Service Personnel Access Relevance
503   All Customer Service Representatives’ (CSR) access shall be limited from a particular network subnet (subnet
504   filtering). The intent is to prevent hackers from anywhere on the Internet from determining a CSR
505   username/password and getting into the system.
506   Anytime a valid CSR username and password is entered in the login screen, a final verification is performed
507   against the set of recognized IP addresses. If someone provides a valid username and password, but is not logging
508   in from a valid IP address, they will not be allowed to log in, although they won't be told why.
509
510   5.7       Caching Requirements
511   This section refers to the minimum requirements for caching. Bidders need to respond with recommended name
512   server caching requirements for time to live (TTL).
513   Preferred range for TTL is 30 minutes to 24 hours.
514
515   5.8       System Turn-Up and Testing
516   Bidders need to provide a detailed start-up project implementation and system test plan, including proposed test
517   cases, to support the Tier 1B registry system turn-up. Bidders are required to provide high level start-up project
518   implementation timelines and plans as part of their bid proposal.
519
520   5.9       Beta ?? Period
521   Editor’s note – need to add details regarding the steps and requirements for the Operational Beta period
522
523   5.10      Operations and Maintenance
524   ENUM is envisioned as a wholly robust and high-availability service t. An ENUM Tier 1B Registry candidate
525   should describe how it would operate and maintain the various aspects of the Registry at a high service level. It
526   should include descriptions of how it intends to ensure system outage prevention, system recovery procedures,
527   and technical support. Bidders should also include descriptions of how they intend to ensure system
528   outage prevention, system recovery procedures, and technical support, including arrangements for
529   power, HVAC (Heating, Ventilating, and Air Conditioning), and fire systems.
530
531   An ENUM Tier 1B Registry candidate should also describe how it intends on meeting the following operations
532   and maintenance requirements.
533   A Registry shall:
534            Use redundancy and high-availability system architectures to eliminate planned or unplanned downtime
535             of the whole system. That is, Registry service shall remain operational when part of the system is
536             undergoing software or hardware upgrades and system backups.
537            Use redundancy and high-availability system architectures to minimize unplanned downtime.

                                                               20
      Tier 1B Technical and Operational Requirements                              CC1 ENUM LLC TAC-08.00001-2005


538          Employ a comprehensive set of system monitoring procedures for problem detection and resolution at
539           multiple levels of the architecture, including processor, memory, operating system, database, application
540           process, and network connectivity.
541          Make available backup software, operating systems and hardware in all data centers.
542          Employ a streamlined technical support process to ensure that the appropriate staffs resolve all
543           problems in a timely manner
544
545   5.11    System Outage Prevention and Recovery
546   An ENUM Tier 1B Registry requires outage prevention measures specifically designed to minimize system
547   component downtime. Downtime relates to individual components in a redundant system and can be either
548   planned or unplanned., Unplanned downtime is caused by failures in external communications, power, or internal
549   network or computer equipment; or planned, which occurs when a system is unavailable due to scheduled
550   maintenance (e.g., during software or hardware upgrades and system backups).
551
552   5.11.1 System Recovery Procedures
553   System recovery refers to the process of bringing the system back to normal operations after the system has gone
554   down due to failures. The goal is to minimize downtime, data loss and adverse impacts on other systems.
555   An ENUM Tier 1B Registry candidate should describe how it intends on meeting the following operations and
556   maintenance requirements.
557   A Registry shall:
558          Employ recovery procedures for failures that occur at different parts of the Registry system, such as:
559               - Data center failures
560               - Database failures
561               - Server failures
562               - Network failures
563          Specify how redundancy and highly-available Registry architecture will help expedite recovery from
564           these failures.
565          Specify how backup and escrow data will be used for recovery from these failures.
566
567   In addition, a Registry should:
568          Provide a time estimate for recovering from each type of failure.
569          Log each system outage and document system problems that could result in outages.
570
571   5.11.2 Database Escrow and Backup
572   The goal of any data backup/recovery procedure is full recovery from failures without any loss of data. Data
573   backup strategies handle system hardware failures (e.g., loss of a processor or one or more disk drives) by
574   reinstalling the data from daily backups, supplemented by the information on the “before” and “after” backup files
575   that the database creates. In order to guard against loss of the entire facility because of fire, flood, or other natural
576   or man-made disaster, off-site escrow of the Registry data should be provided in a secured storage facility.
577   An ENUM Tier 1B Registry candidate shall specify:
578              The frequency and procedures for data backup
579              The frequency and procedures for data escrow
580              The hardware and software systems used for data backup
581              The procedures for retrieval of data and rebuild of the database
                                                                 21
      Tier 1B Technical and Operational Requirements                        CC1 ENUM LLC TAC-08.00001-2005


582             Who should have access to the escrowed data and in what circumstances it would be accessed by an
583              entity other than itself
584             Testing process and schedule to verify the escrow and database backup procedure
585             The data escrow arrangements, including any contractual arrangements with Third parties
586
587   In addition, the following safeguards are required of ENUM Tier 1B Registry candidates:
588         The data backup and escrow procedures shall not impede the overall performance of normal Registry
589          operations
590         The data backup and recovery procedures shall minimize the data loss and service interruption of the
591          Registry
592
593   5.12 Technical and Other Support
594   The Tier 1B Registry must act as technical liaison with Tier 1A for resolution of issues with respect to
595   the delegation of authority over a country’s NPA’s within 1.e164.arpa.
596   The Tier 1B Registry must provide technical and other support to Registrars and Tier 2 service providers
597   from an appropriate customer help desk with a well-defined escalation policy.
598
599         A Registry may provide web-based support to Registrars, Tier 2 service providers, and Internet
600          users at large. The web contents may include knowledge bases, FAQ’s, toolkits, white papers,
601          and email messaging.
602
603   5.13 Other Responsibilities of the Tier 1B Registry
604   The Tier 1B Registry will use commercially reasonable efforts to restore the critical components of the
605   system within 48 hours in the case of a force majeure event. No single event should result in an outage
606   of DNS resolution service itself.
607   Except in the case of nameserver performance requirements, the Tier 1B Registry will perform internal
608   monitoring as a means to verify that the availability and performance measurements of this document
609   are being met.
610   Beginning no later than 120 days after the commencement-of-service date, the Tier 1A Registry will
611   provide preliminary monthly system performance and availability reports to the contracting entity.
612   The Tier 1B Registry will provide service availability percentages during each Performance
613   Measurement Period as listed in this document.
614
615   5.14   Transition
616   (Editor’s Note: Need to add text regarding operations, and system transition to new vendor)
617   The Tier 1B Registry must provide a plan for transitioning of the Registry to a new provider should
618   that be required under the terms of the contract. The plan must ensure no disruption of ENUM DNS
619   service.
620
621   5.15   Accommodation of Future Internet Architectural Enhancements
622   Bidders must respond with plan to accommodate IPv6 per RFC 2874.
                                                            22
      Tier 1B Technical and Operational Requirements                        CC1 ENUM LLC TAC-08.00001-2005


623

624   SECTION 6.0             SERVICE LEVEL REQUIREMENTS (SLR)
625   Editor’s Note – Additional details to be provided by Richard, Tim and Kevin
626   Editor’s Note: Section needs to be synchronized with Tier 1A along with adding additional SRS requirements.
627   This section provides requirements for timeliness and reliability of the ENUM Tier 1B Registry. It also provides
628   metrics for measuring reliability.
629
630   (Editor’s Note: New Definitions proposed need to review Section 3 for additions
631
632
633   6.1     Performance Specifications
634   Registry operator shall use commercially reasonable efforts to provide Registry Services for the Registry
635   TLD. The Performance Specifications defined below establish the basis for the Service Level Exception
636   Credits ("SLE Credits") provided for in a Registry Agreement. These Performance Specifications also
637   set forth Registry Operator's obligations directly to the Tier 1B under the Registry Agreement.
638
639   6.2      Service Availability
640   Service Availability is defined as the time, in minutes, that the Registry's Core Services are responding
641   to its users. Service is unavailable when a service listed in the Matrix is unavailable to all users, that is,
642   when no user can initiate a session with or receive a response from the Registry ("Unavailability").
643   Service Availability is a C1 priority level.
644
645   Service Availability is measured as follows:
646   - Service Availability % = {[(TM - POM) - UOM] / (TM - POM)}*100 where: TM = Total Minutes
647      in the Service Level Measurement Period (#days*24 hours*60 minutes)
648   - POM = Planned Outage Minutes (sum of (i) Planned Outages and (ii) Extended Planned Outages
649      during the Service Level Measurement Period)
650   - UOM = Unplanned Outage Minutes (Difference between the total number of minutes of
651      Unavailability during the Service Level Measurement Period minus POM.
652
653   Upon written request, and at the sole expense of the requesting Registrar(s), Registry Operator will
654   retain an independent third party (to be selected by Registry Operator with the consent of the
655   Registrar(s) to perform an independent calculation of the UOM). The frequency of this audit will be no
656   more than once yearly during the term of the agreement between Registry Operator and the Registrar.
657   This calculation is performed and the results reported for each calendar month for SRS and WHOIS
658   availability and for each calendar year for Nameserver availability.
659
660   6.3    Service Availability - SRS
661   Service Availability as it applies to the SRS refers to the ability of the SRS to respond to Registrars that
662   access and use the SRS through the EPP or designated protocol.. SRS Unavailability will be logged with
663   the Registry Operator as Unplanned Outage Minutes. The committed Service Availability for SRS is
664   99.95% and the Service Level Measurement Period is monthly.
665

                                                            23
      Tier 1B Technical and Operational Requirements                     CC1 ENUM LLC TAC-08.00001-2005


666   1. Service Availability Nameserver Service
667   Service Availability as it applies to the Nameserver refers to the ability of the Nameserver to resolve a
668   DNS query from an Internet user. Nameserver Unavailability will be logged with the Registry Operator
669   as Unplanned Outage Minutes. The committed Service Availability for Nameserver is 100% and the
670   Service Level Measurement Period is annually.
671
672   2. Total Nameserver Availability
673   In addition, no less than 80% of nameserver sites will be available at any given time. For purposes of
674   this SLA, "nameserver site" shall mean distinct locations that host a .NET nameserver(s). For example
675   Sterling, VA, USA and Tokyo, Japan are 2 nameserver sites.
676
677   3. Service Availability
678   WHOIS = 100%. Service Availability as it applies to WHOIS refers to the ability of users to access and
679   use the Registry's WHOIS service. WHOIS Unavailability will be logged with the Registry Operator as
680   Unplanned Outage Minutes. The committed Service Availability for WHOIS is 100% and the Service
681   Level Measurement Period is monthly.
682
683   6.4     Planned Outage
684   High volume data centers like the Registry require downtime for regular maintenance. Allowing for
685   regular maintenance ("Planned Outage") ensures a high level of service for the Registry. Planned Outage
686   Performance Specifications are a C4 priority level.
687
688   1. Planned Outage Duration
689   The Planned Outage Duration defines the maximum allowable time, in hours and minutes that the
690   Registry Operator is allowed to take the Registry Services out of service for regular maintenance.
691   Planned Outages are planned in advance and the Registrar community is provided warning ahead of
692   time (Editor’s Note: What is the minimum notification period). This Performance Specification, where
693   applicable, has a monthly Service Level Measurement Period. The Planned Outage Duration for the
694   Core Services is as follows:
695   - Planned Outage Duration -- SRS = 8 hours (480 minutes) per month, can be split between 2 days;
696   - Planned Outage Duration -- Nameserver = (no planned outages allowed); and
697   - Planned Outage Duration - WHOIS = (no planned outage allowed).
698
699   2. Planned Outage Timeframe
700   The Planned Outage Timeframe defines the hours and days in which the Planned Outage can occur. The
701   Planned Outage Timeframe for the Core Services is as follows:
702   - Planned Outage Timeframe -- SRS = 0500-1300 UTC Sunday;
703   - Planned Outage Timeframe -- Nameserver = (no planned outages allowed); and
704   - Planned Outage Timeframe - WHOIS (no planned outages allowed).
705
706   3. Planned Outage Notification
707   The Registry Operator must notify all of its Registrars of any Planned Outage. The Planned Outage
708   Notification Performance Specification defines the number of days prior to a Planned Outage that the
709   Registry Operator must notify its Registrars. The Planned Outage Notification for the Core Services is as
710   follows:
711   - Planned Outage Notification Timeframe -- SRS = 7 days;
712   - Planned Outage Notification Timeframe -- Nameserver = (no planned outages allowed); and
                                                          24
      Tier 1B Technical and Operational Requirements                   CC1 ENUM LLC TAC-08.00001-2005


713   -     Planned Outage Notification Timeframe - WHOIS (no planned outages allowed).
714
715   6.5     Extended Planned Outage
716   In some cases such as software upgrades and platform replacements an extended maintenance timeframe
717   is required. Extended Planned Outages refers to additional hours that can be added to a monthly planned
718   outage. Extended Planned Outages will occur less frequently than Planned Outages. Extended Planned
719   Outage Performance Specifications are a C4 priority level.
720
721   1. Extended Planned Outage Duration
722   The Extended Planned Outage Duration defines the maximum allowable time, in hours and minutes, that
723   the Registry Operator is allowed to take the Registry Services out of service for extended maintenance.
724   Extended Planned Outages are planned in advance and the Registrar community is provided warning
725   ahead of time. Extended Planned Outage periods are in addition to any Planned Outages during any
726   Service Level Measurement Period. This Performance Specification, where applicable, has a Service
727   Level Measurement Period based on a calendar year. The Extended Planned Outage
728   Duration for the Core Services is as follows:
729   - Extended Planned Outage Duration - SRS = 8 hours (480 minutes) per calendar year;
730   - Extended Planned Outage Duration - Nameserver = (no planned outages allowed); and
731   - Extended Planned Outage Duration - WHOIS (no planned outages allowed).
732
733   2. Extended Planned Outage Timeframe
734   The Extended Planned Outage Timeframe defines the hours and days in which the Extended Planned
735   Outage can occur. The Extended Planned Outage Timeframe for the Core Services is as follows:
736   - Extended Planned Outage Timeframe - SRS = 0100 - 1700 UTC Saturday or Sunday;
737   - Extended Planned Outage Timeframe - Nameserver = (no planned outages allowed); and
738   - Extended Planned Outage Timeframe - WHOIS (no planned outages allowed).
739
740   3. Extended Planned Outage Notification
741   The Registry Operator must notify all of its Registrars of any Extended Planned Outage. The Extended
742   Planned Outage Notification Performance Specification defines the number of days prior to an Extended
743   Planned Outage that the Registry Operator must notify its Registrars. The Extended Planned Outage
744   Notification for the Core Services is as follows:
745   - Extended Planned Outage Notification - SRS = 28 days;
746   - Extended Planned Outage Notification - Nameserver =(no planned outages allowed); and
747   - Extended Planned Outage Notification - WHOIS (no planned outages allowed).
748
749   6.6      Processing Time
750   Processing Time is an important measurement of transaction-based services like the Registry.
751   Processing Time measures the quality of that service.
752
753   Processing Time refers to the time that the Registry Operator receives a request and sends a response to
754   that request. Since each of the Registry Services has a unique function, the Performance Specifications
755   for Processing Time are unique to each of the Registry Services. For example, a Performance
756   Specification for the Nameserver is not applicable to the SRS and WHOIS, etc.
757
                                                        25
      Tier 1B Technical and Operational Requirements                    CC1 ENUM LLC TAC-08.00001-2005


758   Processing Time Performance Specifications are a C2 priority level. Processing Time Performance
759   Specifications have a monthly Service Level Measurement Period and will be reported on a monthly
760   basis. The Registry Operator will log the processing time for all of the related transactions, measured
761   from the time it receives the request to the time that it returns a response.
762
763   1. Processing Time Add, Modify, Delete = 1000 milliseconds for 95%.
764   - Processing Time - Add, Modify, and Delete is applicable to the SRS as accessed through the EPP
765      protocol defined in Appendix C. It measures the processing time for add, modify, and delete
766      transactions associated with domain names, nameservers, contacts, and Registrar profile information.
767   - The Performance Specification is 1000 milliseconds for 95% of the transactions processed. That is,
768      95% of the transactions will take 1000 millisecond or less from the time the Registry Operator
769      receives the request to the time it provides a response.
770
771   2. Processing Time--Query Domain
772   - Processing Time - Query Domain is applicable to the SRS as accessed through the designated
773      protocol. It measures the processing time for an availability query of a specific domain name.
774   - The performance specification is 500 milliseconds for 95% of the transactions. That is, 95% of the
775      transactions will take 500 milliseconds or less from the time the Registry Operator receives the
776      query to the time it provides a response as to the domain name's availability.
777
778   3. Processing Time--WHOIS Query
779   - Processing Time - WHOIS Query is only applicable to the WHOIS. It measures the processing time
780      for a WHOIS Query.
781   - The Performance Specification is 1000 milliseconds for 95% of the transactions. That is, 95% of the
782      transactions will take 1000 milliseconds or less from the time the WHOIS receives a query to the
783      time it responds.
784
785   4. Processing Time--Nameserver Resolution
786   - Processing Time - Nameserver Resolution is only applicable to the Nameserver. It measures the
787      processing time for a DNS query.
788   - The Performance Specification is 250 milliseconds for 95% of the transactions. That is, 95% of the
789      transactions will take 250 milliseconds or less from the time Nameserver receives the DNS query to
790      the time it provides a response.
791
792   5. Update Frequency
793   There are two important elements of the Registry that are updated frequently and are used by the general
794   public; Nameserver and WHOIS. Registrars generate these updates through the SRS. The SRS then
795   updates the Nameserver and the WHOIS. These will be done on a batch basis. Update Frequency
796   Performance Specifications are a C3 priority level.
797
798   The committed Performance Specification with regard to Update Frequency for both the Nameserver
799   and the WHOIS is 10 minutes for 95% of the transactions. That is, 95% of the updates to the
800   Nameserver and WHOIS will be effectuated within 10 minutes. This is measured from the time that the
801   registry confirms the update to the Registrar to the time the update appears in the Nameserver and
802   WHOIS. Update Frequency Performance Specifications have a monthly Service Level Measurement
803   Period and will be reported on a monthly basis.
804   - Update Frequency--Nameserver = 10 minutes for 95%.
                                                         26
      Tier 1B Technical and Operational Requirements                     CC1 ENUM LLC TAC-08.00001-2005


805   -   Update Frequency--WHOIS = 10 minutes for 95%.
806
807   6.7     Cross-Network Nameserver Performance Requirements
808   Nameserver round-trip-time and packet loss from the Internet are important elements of the quality of
809   service provided by the Registry Operator. These characteristics, however, are affected by Internet
810   performance and therefore cannot be closely controlled by Registry Operator. Accordingly, these
811   requirements are not matters subject to Service Level Exceptions and credits under the Service Level
812   Agreement, but they are Registry Operator obligations in the Registry Agreement.
813
814   The committed Performance Specification for cross-network nameserver performance is a measured
815   round-trip time (RTT) of under 300 ms and measured packet loss of under 10%. Cross-network
816   nameserver performance measurements will be conducted by ICANN at times of its choosing, in the
817   following manner:
818
819   The measurements will be conducted by sending strings of DNS request packets from each of four
820   measuring locations to each of the .NET nameservers and observing the responses from the .NET
821   nameservers. (These strings of requests and responses are referred to as a "CNNP Test".) The measuring
822   locations will be 4 locations within the NANP. (Editor’s Note – locations within the country and or
823   NANP need to be specified)
824   - Each string of request packets will consist of 100 UDP packets at 10 second intervals requesting ns
825       records for arbitrarily selected .NET second-level domains, preselected to ensure that the names
826       exist in the Registry TLD and are resolvable. The packet loss (i.e. the percentage of response packets
827       not received) and the average round-trip time for response packets received will be noted.
828   - To meet the packet loss and round-trip-time requirements for a particular CNNP Test, all measured
829       RTTs must be less than 300 ms and these must be less than 10% packet loss.
830   - Any failing CNNP Test result obtained during an identified Core Internet Service Failure shall not
831       be considered.
832   - To ensure a properly diverse testing sample, Registry Operator will contract with a third party to
833       perform the test and provide the results to ICANN and the Registry Operator. The CNNP Tests at
834       varying times (i.e. at different times of the day, as well as on different days of the week). Registry
835       operator will be deemed to have failed to meet the cross-network nameserver performance
836       requirement only if the .NET nameservers persistently fail the CNNP Tests with no less than three
837       consecutive failed CNNP Tests to be considered to have persistently failed.
838   - In the event of persistent failure of the CNNP Tests, the Tier 1B will give the Registry Operator
839       written notice of the failures (with backup data) and Registry Operator will have sixty days to cure
840       the failure. Notice will also be sent to the CC1 ENUM LLC.
841   - If, following that opportunity to cure, the .NET nameservers continue to persistently fail CNNP
842       Tests and Registry Operator fails to resolve the problem after thirty days notice of the continuing
843       failures, Registry Operator will be deemed not to have met its obligations under the Registry
844       Agreement.
845   - Sixty days prior to the commencement of testing under this provision, the Tier 1B will provide the
846       Registry Operator with the opportunity to evaluate the testing tools and procedures to be used by the
847       Tier 1B. In the event that Registry Operator does not approve of such tools and procedures, the Tier
848       1B will work directly with Registry Operator to make necessary modifications.
849



                                                         27
      Tier 1B Technical and Operational Requirements                           CC1 ENUM LLC TAC-08.00001-2005


850   6.8    Responsibilities of the Parties
851   Except in the case of nameserver performance measurements, the Registry Operator will perform
852   monitoring from internally located systems as a means to verify that the availability and performance
853   measurements in this document are being met.
854
855   -     Beginning no later than 90 days post Commencement-of-Service Date, the Registry Operator will
856         publish preliminary weekly system performance and availability reports. Registry operator will use
857         best efforts to finalize these reports no later than 30 days after the preliminary reports are provided.
858   -     The Registry Operator will use commercially reasonable efforts to restore the critical systems of the
859         Core Services within 24 hours after the termination of a force majeure event and restore full system
860         functionality within 48 hours after the termination of a force majeure event. Outages due to a force
861         majeure will not be considered Service Unavailability.
862
863   6.9       Connectivity (with Service Providers)
864   This section describes the requirements for connectivity of the ENUM Tier 1B registry with the Internet. It can
865   include items such as:
866          Multihoming requirements
867          Resilient/Redundant access
868          BGP Peering with ISPs
869
870   An ENUM Tier 1B Registry candidate shall propose service-level requirements it would expect to meet with
871   regard to operations of the ENUM Tier 1B Registry. This shall include the following items:
872            Registry database throughput – number of transactions per second
873            Registry database availability
874            Number of ENUM Registrar accounts
875            Number of concurrent ENUM Registrar-ENUM Registry connections
876            Frequency of zone data generation: rates per day, hour, minute
877            Zone data propagation delay: minutes, seconds
878            Number of nameservers required
879            Frequency of ContactInfo database generation: rates per day, hour, minute
880            ContactInfo query response time
881            ContactInfo query throughput – number of queries per second
882            ContactInfo database availability
883
884   6.10      Performance and Capacity
885   Performance requirements for ENUM Tier 1B Registry include:
886            Raw Throughput supported (e.g., queries per second)
887            Valid throughput (e.g., valid queries & responses per second)
888            Invalid throughput (e.g., how many invalid queries/second without affecting valid operation) ???
889            Average/Mean/… Query/Response delay
890            Registration performance requirements (registrations/unit time)
891            Zone data update frequency (e.g., 5 minute update frequency 95% of the time)
892            Cross-Network Nameserver Performance (as defined by ICANN)
893
                                                               28
      Tier 1B Technical and Operational Requirements                        CC1 ENUM LLC TAC-08.00001-2005


894   Performance will be important. ENUM Tier 0 and ENUM Tier 1A Registries are likely to hold information that
895   is readily available from caches. However, ENUM Tier 1B Registry will hold phone numbers and caches from
896   ENUM Tier 1B Registry hits will not aggregate. For example, a cache of a NPA will cover queries for all phone
897   numbers in the NPA, but a cache of a single phone number will only cover queries for that phone number. Thus
898   the ENUM Tier 1B registry is likely to get more queries.
899   Another aspect of performance will be the query/response metrics as measured from sites around the world. The
900   ENUM Tier 1B Registry must support queries from locations all over the world with acceptable performance.
901
902   6.11    ENUM Tier 1B Registry Performance Specifications
903   An ENUM Tier 1B Registry shall use commercially reasonable efforts to provide performance at the levels set
904   forth herein. (Editor’s Note: Should the Tier 1B bidder provide a proposed registry agreement that
905   outlines the minimum performance specifications)
906
907   6.11.1 DNS Service
908   Performance Specifications
909           •      The performance specification for DNS Queries is 300 milliseconds (ms) maximum round-trip
910                  time.
911   Availability
912           •      A DNS Point of Presence (PoP) is considered to be Available during a Sampling Period if it
913                  responds to DNS Queries within the performance specification for 95% of all Measured
914                  Transactions within that Sampling Period.
915           •      The DNS service is considered to be Available for a Sampling Period if over 99% of the queries
916                  submitted within that sampling period are responded to within the specified round-trip response
917                  time as specified.
918           •      The total unavailability of the SRS systems shall not exceed 5 minutes per calendar year. This
919                  represents 99.999% system availability. There shall be no simultaneous Planned Outage of SRS
920                  service at over half of the System's SRS PoPs.
921           •      The total unavailability of the DNS name service systems shall be 0%. This represents 100%
922                  DNS name service availability. There shall be no simultaneous Planned Outage of DNS service at
923                  over half of the System's DNS name service PoPs.
924           •      Nameservers shall exceed 99.99% availability
925   6.11.2 Planned Outages
926   Planned Outages will not exceed four (4) hours per calendar week beginning at 0000 GMT Monday, nor total
927   more than eight (8) hours per month. Notwithstanding the foregoing, the Tier 1 Registry may incur one (1)
928   additional Planned Outage of up to eight (8) hrs. per month in duration for major systems or software upgrades
929   (Extended Planned Outages). In months in which Extended Planned Outages occur, no other Planned Outages
930   may occur.
931
932   6.11.3 Updates
933   The Update Time for the DNS service shall not exceed 5 minutes for 95% of all updates.
934



                                                            29
      Tier 1B Technical and Operational Requirements                        CC1 ENUM LLC TAC-08.00001-2005


935   6.11.4 Cross Network Nameserver Performance Requirements
936   The committed performance specifications for cross-network nameserver performance is a measured round-trip
937   time of less than 300 ms and measured packet loss of less than 10%. The cross-network nameserver performance
938   requirements of this subsection are in addition to the requirements of subsections above. Cross-network
939   nameserver performance (CNNP) measurements will be conducted by a neutral third party, at times of its
940   choosing, in the following manner:
941          •       The measurements will be conducted by sending strings of DNS request packets from each of
942                  four measuring locations, chosen by the neutral third party, to each of the Tier 2 nameservers and
943                  observing the responses from the Tier 2 nameservers. The measuring locations will be four
944                  locations, which are geographically dispersed in the U.S. Time Zone.
945          •       Each string of request packets will consist of 100 DNS Queries at 10 second intervals requesting
946                  nameserver type resource records for arbitrarily selected ENUM Tier 1B Registry domains,
947                  preselected to ensure that the names exist in the Tier 1 Registry and are resolvable. The packet
948                  loss (i.e., the percentage of response packets not received) and the average round-trip time for
949                  response packets received will be noted.
950          •       To meet the packet loss and round-trip time requirements for a particular CNNP Test, all three of
951                  the following must be true:
952                  (1) The round-trip time and packet loss from each measurement location to at least one ENUM
953                  Tier 1B nameserver must not exceed the required values.
954                  (2) The round-trip time to 75% of the ENUM Tier 1B nameservers from at least one of the
955                  measurement locations must not exceed the required value.
956                  (3) The packet loss to each of the Tier 1B nameservers from at least one of the measurement
957                  locations must not exceed the required value.
958          •       Any failing CNNP Test result obtained during an identified core Internet service failure shall not
959                  be considered.
960          •       To ensure a properly diverse testing sample, a neutral third party will conduct the CNNP Tests at
961                  varying times (i.e., at different times of the day, as well as on different days of the week). An
962                  ENUM Tier 1B Registry will be deemed to have failed to meet the cross-network nameserver
963                  performance requirement only if the Tier 1B nameservers persistently fail the CNNP Tests.
964                  Persistently failed is defined as the failure of three or more consecutive CNNP tests.
965          •       In the event of persistent failure of the CNNP Tests, the neutral third party will give an ENUM
966                  Tier 1B Registry written notice of the failures (with test data) and the ENUM Tier 1B Registry
967                  will have sixty days to cure the failure.
968          •       If, following that opportunity to cure, the Tier 1B nameservers continue to persistently fail CNNP
969                  Tests and an ENUM Tier 1B Registry fails to resolve the problem after thirty days notice of the
970                  continuing failures, an ENUM Tier 1B Registry will be deemed not to have met its performance
971                  obligations.
972          •       Sixty days prior to the commencement of testing under this provision, the neutral third party will
973                  provide the ENUM Tier 1B Registry with the opportunity to evaluate the testing tools and
974                  procedures to be used. In the event that the ENUM Tier 1a Registry does not approve of such
975                  tools and procedures, the neutral third party will work directly with the ENUM Tier 1B Registry
976                  to make necessary modifications.
977          •       The neutral third party shall make available all data relating to CNNP Test results of the ENUM
978                  Tier 1B nameservers to the ENUM Tier 1B Registry. Data will be made available in a well-


                                                            30
       Tier 1B Technical and Operational Requirements                             CC1 ENUM LLC TAC-08.00001-2005


979                    defined electronic format no later than the tenth day of the month following the month in which
980                    measurements were taken.
981    6.11.5 EPP Performance Specifications
982           •     The performance specification for add, modify and delete commands is 3000 milliseconds. This
983                 is measured from the time the command is completely received until it is completely sent. It is
984                 important to note that this specification may not be met during periods of extreme volume.
985            •       The performance specification for check commands is 1500 milliseconds. This is measured from
986                    the time the command is completely received until it is completely sent. It is important to note
987                    that this specification may not be met during periods of extreme volume.
988    The total planned outage should correspond with the specifications set forth herein.
989
990    6.11.6 Responsibilities of the Parties
991    The ENUM Tier 1B Registry will use commercially reasonable efforts to restore the critical components of the
992    system within 48 hours in the case of a force majeure event. Outages due to a force majeure event will not be
993    considered System Unavailability. (Editor’s note – check on NPAC requirements for reference information to use
994    as guide for text to include in this section)
995    Except in the case of nameserver performance requirements, the ENUM Tier 1B Registry will perform internal
996    monitoring as a means to verify that the availability and performance measurements of this document are being
997    met.
998    Beginning no later than 120 days after the commencement-of-service date, the ENUM Tier 1B Registry will
999    provide preliminary monthly system performance and availability reports to the contracting entity.
1000   The ENUM Tier 1B Registry will provide service availability percentages during each Performance Measurement
1001   Period as listed in this document.
1002
1003   6.12    ENUM Tier 1B Registry Management
1004   This section provides requirements for the management and monitoring of events in the ENUM Tier 1B Registry
1005   system. This includes logging of events, auditing logs and notification of significant events to personnel for
1006   remedial action.
1007          Reject illegal commands/requests (e.g., missing mandatory data element) from ENUM Registrars
1008          Detect dual registrations for the same ENUM domain name and inform the requesting ENUM Registrar
1009           so that it can initiate the dispute resolution process. If a Registrar initiations a dispute resolution process
1010           the Tier 1B will notify the original Registrar of the dispute. The ENUM Tier 1B Registry must take
1011           appropriate action to protect the integrity of the original registration during the dispute resolution process.
1012
1013   6.12.1 Reports and Files
1014   (Action Item – Richard/Kevin contribution on reports to that need to be provided)
1015   An ENUM Tier 1B Registry shall provide reporting service to ENUM Registrars and the contracting entity In
1016   addition, it may also make available zone data and ContactInfo data to ENUM Registrars and other contracting
1017   entities. [It’s one thing to make available the zone data entries corresponding to a ENUM Registrar’s
1018   registrations, but the whole zone data should not be made available.]
1019   ENUM Tier 1B Registry reports for Registrars may include:
1020          Daily Reconciliation Reports created from account transaction logs
1021          Daily and Monthly ENUM Registrar Cumulative Reports for domain-name registrations
                                                                 31
       Tier 1B Technical and Operational Requirements                        CC1 ENUM LLC TAC-08.00001-2005


1022          Transaction logs
1023          Complete database export file of all data entities owned
1024          ENUM Tier 1B Registry reports for the Contracting Agency may include: Total ENUM domain-name
1025           strings processed
1026          Total ENUM domain-names "registered"
1027          [What does “unavailable” refer to???] Total ENUM domain-name strings "unavailable"
1028          Total ENUM domain-name strings "invalid"
1029
1030   An ENUM Tier 1B Registry may provide custom reporting service that would allow ENUM Registrars and the
1031   Contracting Agency to specify report criteria and have the report available for download upon completion.
1032   Example reports are:
1033       Number and name of domain-names registered within any period
1034       Domain-names transferred to/away from ENUM Registrar within a specified period
1035       Change of ownership activity, and time/date requests were processed
1036       Re-delegation activity
1037   These reports should be posted to a secure site (i.e., FTP (File Transfer Protocol)) that can be accessed by the
1038   ENUM Registrars by entering username and pass code.
1039   The format for reports should be easily machine-readable by ENUM Registrars (i.e., XML, CSV).
1040   Naming convention of reports should identify the ENUM Registrars, the date the report was created and indicate
1041   the subject of the report.
1042   An ENUM Tier 1B Registry should archive copies of all reports created.
1043   An ENUM Tier 1B Registry candidate is required to address what mechanisms it would use to enable the
1044   contracting entity to:
1045           •       Monitor the initial progress of implementation
1046           •       Monitor the ongoing participation in the offering
1047           •       Monitor and provide feedback regarding the ongoing performance of the Tier 1
1048           •       Monitor ongoing system updates and changes
1049           •       Monitor ongoing policy updates and changes
1050           •       Drive system updates and changes
1051           •       Drive policy updates and changes

1052   SECTION 7.0 REGISTRY-REGISTRAR INTERFACE REQUIREMENTS
1053
1054   The Tier 1B Registry must establish an interface which is available for all ENUM Registrars to use. The common
1055   protocol may be EPP, but this should not preclude other protocols being used between the ENUM Registry and
1056   ENUM Registrars. The protocols to be used on the interface between the ENUM Tier 1B Registry and ENUM
1057   Registrars must be agreed between those parties.
1058   7.1    Shared Registration System (SRS)
1059   A Tier 1B Registry is envisioned as a shared registration system (SRS) whereby accredited competing
1060   Registrars may register ENUM domain names for their customers in the CC1 ENUM name space. The
1061   Tier 1B Registry will be required to develop a Registrar Accreditation process and Registry-Registrar
1062   agreement. The Tier 1B Registry will be prohibited from functioning as a Registrar.
1063


                                                             32
       Tier 1B Technical and Operational Requirements                     CC1 ENUM LLC TAC-08.00001-2005


1064   A Tier 1B SRS is required to:
1065      Allow an unlimited number of accredited Registrars to register ENUM domain names in the CC1
1066       ENUM name space
1067      Provide equal access to the system for all accredited Registrars to perform registration related
1068       operations such as:
1069           - Register new ENUM domain names, Tier 2 contacts, or host names
1070           - Check status of registered ENUM domain names, Tier 2 contacts, or host names
1071           - Delete registered ENUM domain names, Tier 2 contacts, or host names
1072           - Renew registered ENUM domain names, Tier 2 contacts, or host names
1073           - Update information about registered ENUM domain names, Tier 2 contacts, or host names
1074           - Transfer ENUM domain name registration among competing accredited Registrars
1075      Support the open standard interface between the Registry and accredited Registrars, as defined in the
1076       IETF extensible provisioning protocol (EPP) standard suite (RFC3730 through RFC3735). The Tier
1077       1B Registry will work with the CC1 ENUM industry to develop extensions to EPP for the purposes
1078       of supporting CC1 ENUM.
1079      New bullet – The common Tier 1B registry protocol for registrars shall be EPP but this should not
1080       preclude other protocols from being used between the registry and registrars. Alternative protocols
1081       must be an open standard and agreed to by both parties. Once an alternative protocol has been
1082       established by the Tier 1B registry other registrars may also use that interface after notification and
1083       agreement of the Tier 1B registry. (Favored Nation Clause)
1084      Support the “thick registry” model whereby Tier 2 contact1 information about ENUM domain name
1085       registrations is stored in the SRS.
1086      Reject illegal commands/requests (e.g., missing mandatory data element) from ENUM Registrars.
1087      Detect dual registrations for the same ENUM domain name and inform the requesting ENUM
1088       Registrar.
1089      Follow proscribed procedures for updating the zone files and information in the local data stores for
1090       handling area code splits.
1091      Security of the SRS applications shall be provided in part via the mandatory use of the TLS [RFC
1092       2246] protocol for transport layer security.
1093      Each EPP session shall be authenticated and encrypted using TLS. The ENUM Registry shall
1094       authenticate every EPP client connection using both an X.509 server certificate, issued by a
1095       commercial Certification Authority identified by the Tier 1 Registry, and its ENUM Registrar
1096       password.
1097      Security of the SRS application shall be provided via a mandatory authenticated and encrypted
1098       connection. At a minimum, IPSEC will be used to secure the connection.
1099      Each EPP session shall be authenticated and encrypted using IPSEC. The ENUM Registry shall
1100       authenticate every EPP client connection using a valid PKI.
1101
       1
1102    This may be extended to include the contact data of the Registrant, but this would be in the context of
1103   an escrow for the Registrar and not that the Registry would publicly display this data or otherwise make
1104   it available.
1105
1106   [Possibly include Service Level requirements regarding planned outages, EPP performance
1107   specifications, etc.]
1108
                                                           33
       Tier 1B Technical and Operational Requirements                              CC1 ENUM LLC TAC-08.00001-2005


1109   Editor’s Note – Check on registry/registrar contents for alignment
1110        Support batch file processing so that the ENUM Registrar can put many commands into one file and
1111           deposit it in a “command” directory on a Tier 1 B Registry server. The Tier 1 B Registry should move
1112           the file to an archive directory, process the commands based on the order as they appear in the file, and
1113           put all the responses to the commands in the same order in a file that is deposited in a “response”
1114           directory on the same server. ENUM Registrars can periodically check and retrieve files in the
1115           “response” directory. Once the file is read, the ENUM Tier 1B Registry can move the file to an archive
1116           directory where it can be preserved as back-up.
1117        Shall support ENUM Registrars’ operations on Registry objects such as create, query, update, delete and
1118           transfer, as specified by the EPP standards suite.
1119
1120   7.2     Interfaces between ENUM Tier 1A Registry and Tier 1B Registry
1121   Because the Tier 1A registry will likely contain less than a thousand records and additions and changes are
1122   expected to be infrequent, a formal mechanized interface or system (Shared Registration System between Tier
1123   1Bs and the Tier 1A may not be required.
1124
1125   7.3     Interfaces between ENUM Tier 1B and ENUM Registrars
1126   Editor’s note – see separate document - registry and registrar interfaces
1127   This interface may be used by the ENUM Registrar to manage their account with the Tier 1 Registry
1128   [EDITOR”S NOTE - Need to further investigate/document the applicant’s authentication requirements
1129   to be an ENUM Applicant]
1130
1131   7.4     Interfaces between ENUM Tier 1B and Tier 2 Registries
1132   This interface may be used by the Tier 1B Registry to discuss the DNS operation problems with the Tier 2
1133   Provider if it is the technical contact for the ENUM domain name.
1134   Only the interface between the ENUM Registrar and the Tier 1B Registry is subject to formal standardization.
1135   The interface between the ENUM Registrar and the Tier 2 Provider may be subject to formal standardization if
1136   there is a strong interest to do so. The interface between the ENUM Registrar and the ENUM Registrant is likely
1137   to be defined by each ENUM Registrar. The interface between the ENUM Registrant and the Tier 2 Provider is
1138   likely to be defined by each Tier 2 Provider. The interface between the Tier 1B Registry and the Tier 2 Provider
1139   can be as simple as a telephone call or e-mail message about a DNS operation problem.

1140
1141
1142
1143

1144   SECTION 8.0              PROVISIONING
1145   EDITORS NOTE: FOLOWING TEXT TAKEN FROM ENUM FORUM 6000 DOCUMENT.
1146   Need to review the use of WHOIS or need for replacing with ContactInfo
1147   This section defines provisioning requirements and procedures for ENUM administration. This involves
1148   the following ENUM functional entities: ENUM Registrar, ENUM Tier 1B Registry, Tier 2 Provider,
1149   Application Service Provider (ASP), and ENUM Registrant. This section will address the tasks and

                                                                34
       Tier 1B Technical and Operational Requirements                            CC1 ENUM LLC TAC-08.00001-2005


1150   responsibilities required to provision and maintain ENUM registrations by the above functional entities
1151   with the focus on the interface between the Tier 1B Registry and the ENUM Registrar.
1152   (NOTE: NEED TO CECK TO SEE IF THESE FOLLOWING ITEMS SHOULD BE
1153   RETAINED)
1154   This section does not include the procedures and interface involving the Tier 0 Registry.
1155   The data elements that may be provided to the Tier 1B Registry are shown in Section 8.5.
1156   The procedures for authentication and authorization are detailed in Section xx
1157   The process for resolution of disputed registrations is detailed in Section xx of this document.
1158
1159   8.1       Assumptions
1160   The following assumptions are made when describing the provisioning scenarios:
1161            ENUM Registrars have an established trust relationship with the Tier 1B Registry. This
1162             relationship includes the method for secure communication, the assignment of a user
1163             identification (ID) and password for session management, a Registrar ID for ENUM Registration
1164             identification, and exchange of contact and other information before ENUM registrations begin.
1165             How to open a secure communication link and establish a session between a Tier 1B Registry
1166             and an ENUM Registrar is not included in the provisioning procedures.
1167            There is no need to provide the IP addresses that are associated with the nameservers as part of
1168             the provisioning process because those nameservers are not likely to be under the .arpa zone (i.e.,
1169             they are the out-of-zone hosts).
1170            An ENUM Registrar can offer Tier 2 Provider service. It can either operate the nameservers
1171             itself, or outsource the nameserver operation to other Tier 2 Providers.
1172            The entity that serves as the Tier 1B Registry for a number cannot also serve as an ENUM
1173             Registrar. This stricture is intended to prevent conflicts of interest on the part of the Registry.
1174             The ENUM Forum's recommendation for implementation of a "thick registry" or escrow model
1175             on which these procedures are based is contingent on this assumption.
1176            Zone file generation, publication/distribution, and updates at the Tier 1B Registry and Tier 2
1177             Providers are not included in this document. They are internal operational procedures.
1178            The procedures for each scenario will cover both successful and failed cases.
1179            Detailed data elements and procedures related to authorization, authentication and accounting
1180             (AAA) between entities other than the Registrant and Registrar are not addressed.
1181            The ENUM Registrant specifies the billing and administrative contact information. He/she
1182             provides the technical contact information only when he/she operates the Tier 2 Providers for
1183             his/her ENUM domain name.
1184            ENUM Registrant may authorize its Tier 2 Provider to review/update certain data (e.g., host and
1185             technical contact information) at its ENUM Registrar and/or its ASPs to review/update some
1186             application-related data for his/her ENUM domain name. The data elements and procedures
1187             related to the interactions between the Tier 2 Provider and the ENUM Registrar, or between
1188             ASPs and Tier 2 Providers are not addressed to simplify the scenario descriptions.

                                                                35
       Tier 1B Technical and Operational Requirements                          CC1 ENUM LLC TAC-08.00001-2005


1189            This section does not address reseller requirements. (Note: need to determine reseller
1190             requirements)
1191            Since this section's focus is on things related to the interface between the Tier 1B Registry and
1192             the ENUM Registrar, it will not address scenarios that do not involve the Registry-Registrar
1193             interface. This includes the scenario where one Tier 1B Registry transfers some or all of its
1194             ENUM registrations to another Tier 1B Registry. Scenarios where the Tier 2 Provider initiates
1195             the action (e.g., check/change data) are not included.
1196            In case of an area code split, the same Tier 1B Registry that handles the old area code will
1197             always handle the new area code.
1198
1199   8.2       Provisioning Requirements
1200   This section lists, or cross-references, the high level requirements for the entities involved in provisioning the
1201   ENUM. In terms of provisioning for ENUM, more stringent and specific requirements will be placed on the Tier
1202   1B Registry and the ENUM Registrars. The Tier 2 Provider, although still subject to certain requirements, will
1203   have more freedom to interact with ENUM Registrants, and optionally, with the ASPs and the ENUM Registrar in
1204   terms of the protocols and/or methods for interactions.

1205   8.2.1 Tier 1B Registry
1206   Tier 1B provisioning requirements are identified in Section xx of this document.

1207   8.2.2 ENUM Registrar
1208   ENUM Registrar requirements are specified in Section xx.
1209   The ENUM Registrar must verify the following:
1210            When dealing with a corporate ENUM Registrant, only those specific persons who are the designated
1211             contact persons of the corporate account with the telephony service provider (TSP) can request ENUM
1212             registration for any TN used by that corporation.
1213            When a broker/agent is involved in applying for ENUM, the broker/agent must be authorized by the TN
1214             assignee/ENUM Registrant to register for ENUM.
1215
1216   The ENUM Registrar must support the protocols specified between the Tier 1 Registry and the ENUM Registrars.
1217   The protocols include those for application handling; secure communications and low-layer transport and routing.
1218   The ENUM Registrar must follow the policies specified for ENUM provisioning (e.g., various grace periods,
1219   transfer and renewal).
1220   The ENUM Registrar should notify the technical contact associated with each ENUM domain name impacted by
1221   an area code split following the recommended procedures in Section 8.4.
1222   If the ENUM Registrar also offers the Tier 2 Provider function to the ENUM Registrant, it must support all the
1223   requirements a Tier 2 Provider must support. If it outsources those functions with a Tier 2 Provider, it must
1224   collect the NAPTR resource record (RR) information or sufficient information that allows that Tier 2 Provider to
1225   provision the NAPTR RRs from the ENUM Registrant.

1226   8.2.3 Tier 2 Provider
1227   The Tier 2 Provider requirements are found in Section XX.



                                                              36
       Tier 1B Technical and Operational Requirements                         CC1 ENUM LLC TAC-08.00001-2005


1228   8.2.4 ENUM Registrant
1229   The ENUM Registrant shall register only the TN or TNs assigned to them.
1230   The ENUM Registrant should inform the ENUM Registrar when he/she disconnects the telephony service (e.g., is
1231   no longer the TN assignee).
1232   If an ENUM Registrant operates the Tier 2 Provider function, it should support the requirements in Section 13.

1233   8.2.5 Application Service Provider (ASP)
1234   The ASPs must give the correct application addresses/URLs to the ENUM Registrant. They may interact with the
1235   Tier 2 Provider in provisioning certain data related to their application service when authorized by the ENUM
1236   Registrant.
1237   Some of the ASPs’ application services may require further resolution services, such as Lightweight Directory
1238   Access Protocol (LDAP) to retrieve application-related information. In that case, ASPs must ensure that the
1239   correct information is provisioned in the NAPTR RRs stored at Tier 2 Providers.
1240
1241   8.3       Provisioning Procedures
1242   This section describes various possible scenarios for ENUM Provisioning Activities.

1243   8.3.1     Scenario – Registrant Selects the Tier 2 Provider at Initial ENUM Registration
1244   In this scenario, the ENUM Registrant selects the Tier 2 Provider before approaching an ENUM
1245   Registrar for ENUM registration.

1246   8.3.1.1 Assumptions
1247            The ENUM Registrant deals with the ENUM Registrar for registering ENUM for his/her
1248             Telephone Number (TN). No agent or broker is involved.
1249            The Tier 2 Provider is selected by the ENUM Registrant as the technical contact for the
1250             registered ENUM domain name. The ENUM Registrant is the billing and administrative contact
1251             for the registered ENUM domain name.

1252   8.3.1.2 Proposed Provisioning Procedures
1253                1. An individual ENUM Registrant selects the Tier 2 Provider and provides the following
1254                   information to that Tier 2 Provider:
1255                   One of the two below:
1256                        1. Naming Authority Pointer (NAPTR) Resource Records (RRs).
1257                        2. If the Tier 2 Provider can formulate the NAPTR RRs:
1258                                   - TN.
1259                                   - Application-related information (e.g., application/service types, email
1260                                      addresses, SIP, fax, TN, URLs) and the preference value, if specified, for
1261                                      each application-related address.
1262                   The ENUM Registrant's contact information. See Section XX for details.
1263                   Any AAA (Authentication, Authorization and Accounting) related information required
1264                    by the Tier 2 Provider.

                                                              37
       Tier 1B Technical and Operational Requirements                       CC1 ENUM LLC TAC-08.00001-2005


1265          2. The Tier 2 Provider verifies the information provided by the ENUM Registrant (e.g., for the purpose
1266             of accounting/payment), sets up a user account with the ENUM Registrant and acknowledges the
1267             receipt of the information.
1268          3. If the account is not approved (e.g., due to bad credit), the Tier 2 Provider informs the ENUM
1269             Registrant about its decision. The ENUM Registrant either gets the rejection reversed and continues
1270             with Step 4, or selects another Tier 2 Provider and goes back to Step 1. He/she may also decide not
1271             to have an ENUM registration at all.
1272          4. If the account is approved, the Tier 2 Provider assigns at least two nameservers, provides the
1273             following information to the ENUM Registrant, and updates the zone file for this ENUM domain
1274             name at the assigned nameservers:
1275                A list of nameserver host names associated with the ENUM domain name
1276                Contact information for the technical contact person for the ENUM domain name
1277          5. The ENUM Registrant selects an ENUM Registrar and provides the following information to that
1278             ENUM Registrar to register for ENUM for his/her TN:
1279                TN
1280                A list of nameserver host names associated with the ENUM domain name
1281                ENUM registration period (e.g., two years)
1282                ENUM Registrant's information and technical, administrative and billing contact
1283                 information
1284                Any AAA-related information required by the ENUM Registrar
1285          6. The ENUM Registrar may interact with the ENUM Registrant for more information if needed. The
1286             ENUM Registrar then validates the ENUM Registrant's identity and TN assignment (methodology
1287             and procedures are defined in Section xx).
1288          7. If the validation fails, the application for ENUM is rejected as to the unauthorized ENUM Registrant
1289              and the entire process stops. The ENUM Registrant, however, if the valid TN assignee, either: (1)
1290              provides more information to have the rejection reversed and continues with Step 8; or (2) selects
1291              another ENUM Registrar and returns to Step 5. He/she also may decide not to register for ENUM.
1292          NOTE: If the ENUM Registrant is not authorized to register the ENUM domain name (e.g., not the TN
1293          assignee), it is that ENUM Registrant's responsibility to cancel its contract with the selected Tier 2
1294          Provider.
1295          8. If the validation is successful, the ENUM Registrar may check whether it has an existing ENUM
1296             registration for the same ENUM domain name from a different ENUM Registrant.
1297                If YES, the ENUM Registrar initiates the dispute resolution process (methodology and
1298                 procedures defined in Section xx) and this process stops.
1299                If NOT, the ENUM Registrar proceeds with Step 9.
1300          9. The ENUM Registrar registers the ENUM domain name with the Tier 1B Registry by providing the
1301             following information:
1302                Request for new ENUM domain name registration
1303                ENUM domain name (e.g., 4.3.2.1.3.3.5.2.0.2.1.e164.arpa)
1304                A list of nameserver host names

                                                            38
       Tier 1B Technical and Operational Requirements                        CC1 ENUM LLC TAC-08.00001-2005


1305                ENUM Registration period (e.g., two years)
1306                The ENUM Registrant's contact information and technical, administrative and billing contact
1307                 information
1308          10. After successful authentication and authorization checks of the ENUM Registrar, the Tier 1B
1309              Registry determines whether there is an existing ENUM registration for the same ENUM domain
1310              name.
1311                If YES, it initiates the dispute resolution process (methodology and procedures defined in
1312                 the Section 14) and this process stops.
1313                If NOT, the Tier 1B Registry acknowledges to the ENUM Registrar that the ENUM domain name
1314                 registration is accepted with a registration expiration date. The Tier 1 Registry then performs the
1315                 zone file updates to add the NS RRs of this ENUM domain name to its nameservers. After the
1316                 zone file updates have been performed at the Tier 1 Registry, real-time DNS queries for this
1317                 particular ENUM domain name will be able to retrieve the nameserver information where
1318                 NAPTR RRs are hosted.
1319                    After receiving the positive acknowledgement from the Tier 1 Registry, the ENUM
1320                     Registrar records this successful ENUM registration and may inform the ENUM
1321                     Registrant about the successful registration of his/her ENUM domain name.




                                                            39
       Tier 1B Technical and Operational Requirements                        CC1 ENUM LLC TAC-08.00001-2005



                                                      Registrant selects
                                                           Tier 2



                                                        Tier 2 verifies
                                                           account
                                                       information and
                                                       creates account


                                                       Tier 2 assigns
                                                       nameservers,
                                                        gives info to
                                                       Registrant and
                                                      updates zone file

                                                      ENUM Registrant
                                                      selects Registrar
                                                          and provides
                                                        registration data


                       Registration denied    fails   Registrar validates
            END                                       Registrant identity
                       Registrant must
                                                      and TN assignment
                       cancel Tier 2

                                                                  succeeds
                       Registrar initiates            Registrar checks
                       conflict resolution     YES    for existing
                       process
                                                      registration for TN


                                                             no
                                                       Registrar sends
                                                         registration
                                                      request to Tier 1B
                                                           Registry


                                                          Registry
                                                        authenticates
                                                          Registrar


                                                                                  Registry updates
                                                       Registry checks
                                             YES                                  Tier 1 B zone file   END
                                                          for existing
                                                                                     and returns
                                                      registration for TN
                                                                                  acknowledgement


1322
1323                         FIGURE 2 – Flow Chart for 8.3.1.2: ENUM Registrant Selects
1324                                   Tier 2 Provider at Initial ENUM Registration

                                                             40
       Tier 1B Technical and Operational Requirements                     CC1 ENUM LLC TAC-08.00001-2005


1325   8.3.2   Scenario – Registrant Did Not Select the Tier 2 Provider at Initial ENUM Registration
1326   An individual ENUM Registrant does not select the Tier 2 Provider before approaching an ENUM
1327   Registrar for ENUM registration. The ENUM Registrar does not support the Tier 2 Provider functions
1328   but out sources those functions to a Tier 2 Provider.

1329   8.3.2.1 Assumptions
1330          The ENUM Registrant interfaces with an ENUM Registrar for registering his/her Telephone
1331           Number (TN) in ENUM. No agent or broker is involved.
1332          The ENUM Registrar and a Tier 2 Provider have a business relationship and have an established
1333           trust relationship if the ENUM Registrar uses a Tier 2 Provider. This includes the method for
1334           secure communication, the assignment of a user id and password for session management,
1335           possibly a Registrar ID for ENUM Registration identification, and exchange of contact and other
1336           information before ENUM registrations begin. How to open a secure communication link and
1337           establish a session between the Registrar and the Tier 2 Provider is not included in the
1338           provisioning procedures.

1339   8.3.2.2 Proposed Provisioning Procedures
1340       1. The ENUM Registrant selects an ENUM Registrar and provides the following information to
1341          that ENUM Registrar to register his/her TN:
1342              TN
1343              ENUM registration period (e.g., two years)
1344              ENUM Registrant's information and administrative and billing contact information
1345              Application-related information (e.g., application/service types, email addresses, SIP, fax,
1346               TN, and URLs) and the preference value, if specified, for each application-related address.
1347              Any AAA-related information required by ENUM Registrar.
1348       2. The ENUM Registrar may interact with the ENUM Registrant for more information if needed.
1349          The ENUM Registrar then validates the ENUM Registrant's identity and TN assignment
1350          (methodology and procedures defined in Section XX).
1351       3. If the validation fails, the application for ENUM is rejected as to the unauthorized ENUM
1352          Registrant and the entire process stops. The ENUM Registrant, however, if the valid TN
1353          assignee, either: (1) provides more information to get the rejection reversed and continue with
1354          Step 4; or (2) selects another ENUM Registrar and returns to Step 1. He/she also may decide not
1355          to register for ENUM.
1356       4. If the validation is successful, the ENUM Registrar may check whether it has an existing ENUM
1357          registration for the same ENUM domain name from a different ENUM Registrant.
1358               a. If YES, the ENUM Registrar initiates the dispute resolution process (methodology and
1359                  procedures defined in the Section 14) and this process stops.
1360               b. If NOT, the ENUM Registrar proceeds with Step 5.
1361       5. The ENUM Registrar selects the Tier 2 Provider and provides the following information to that
1362          Tier 2 Provider:

                                                           41
       Tier 1B Technical and Operational Requirements                   CC1 ENUM LLC TAC-08.00001-2005


1363          One of the two below:
1364   1) Naming Authority Pointer (NAPTR) Resource Records (RRs); OR
1365                  2) If Tier 2 Provider formulates the NAPTR RRs:
1366                         a) TN or ENUM domain name.
1367                         b) Application-related information (e.g., application/service types, email
1368                         addresses, SIP, fax, TN, and URLs) and the preference value, if specified, for
1369                         each application-related address.
1370      6. The Tier 2 Provider assigns at least two nameservers, provides the following information to the
1371         ENUM Registrar and updates the zone file for this ENUM domain name at the assigned
1372         nameservers:
1373             A list of nameserver host names associated with the ENUM domain name
1374             Contact information for the technical contact for the ENUM domain name
1375          (See section XX for details)
1376      7. The ENUM Registrar registers the ENUM domain name with the Tier 1B Registry by providing
1377         the following information:
1378                 Request for new ENUM domain name registration
1379                 ENUM domain name (e.g., 4.3.2.1.3.3.5.2.0.2.1.e164.arpa)
1380                 A list of nameserver host names
1381                 ENUM Registration period (e.g., two years)
1382                 The ENUM Registrant's contact information and technical, administrative and billing
1383                  contact information.
1384      8. After successful authentication and authorization checks of the ENUM Registrar, the Tier 1B
1385         Registry determines whether there is an existing ENUM registration for the same ENUM domain
1386         name.
1387              a. If YES, it initiates the dispute resolution process (methodology and procedures defined in
1388                 the Dispute Resolution Section 14) and this process stops.
1389              b. If NOT, the Tier 1B Registry acknowledges to the ENUM Registrar that the ENUM
1390                 domain name registration is accepted with a registration expiration date. The Tier 1B
1391                 Registry then performs the zone file updates to add the NS RRs of this ENUM domain
1392                 name to its nameservers. After the zone file updates have been performed at the Tier 1B
1393                 Registry, real-time DNS queries for this particular ENUM domain name will be able to
1394                 retrieve the nameserver information where NAPTR RRs are hosted.
1395      9. After receiving the positive acknowledgement from the Tier 1B Registry, the ENUM Registrar
1396         records this successful ENUM registration and may inform the ENUM Registrant about the
1397         successful registration of his/her ENUM domain name.




                                                         42
       Tier 1B Technical and Operational Requirements                           CC1 ENUM LLC TAC-08.00001-2005


                                               Registrant selects
                                                 Registrar and
                                                    provides
                                                registration data


                     Registration        fails Registrar validates
                       denied                  Registrant identity
       END
                                                    and TN
                                                  assignment
                                                                succeeds
                   Registrar initiates   yes    Registrar checks
                   conflict resolution             for existing
                        process                registration for TN


                                                                 no
                                               Registrar selects
                                                Tier 2 provider
                                               and provides data



                                                 Tier 2 assigns
                                               NSs, provides info
                                                to Registrar and
                                               updates zone file


                                                Registrar sends
                                                  registration
                                               request to Tier 1B
                                                    Registry


                                                   Registry
                                                 authenticates
                                                   Registrar



                                                Registry checks            no    Registry updates
                                                   for existing                   Tier 1B zone file
                                         yes                                                          END
                                               registration for TN                  and returns
                                                                                 acknowledgement

1398
1399                                       FIGURE 3 – Flow Chart for 8.3.2.2:
1400                   ENUM Registrant did not select Tier 2 Provider at Initial ENUM Registration




                                                           43
       Tier 1B Technical and Operational Requirements                    CC1 ENUM LLC TAC-08.00001-2005


1401   8.3.3   Corporate Registrant Selects the Tier 2 Provider at Initial ENUM Registration
1402   A corporate ENUM Registrant selects the Tier 2 Provider before approaching an ENUM Registrar for
1403   ENUM registration.

1404   8.3.3.1 Assumptions
1405          The ENUM Registrant deals with the ENUM Registrar for registering his/her Telephone Number
1406           (TN). No agent or broker is involved.
1407          The Tier 2 Provider selected by the ENUM Registrant is the technical contact for the registered
1408           ENUM domain name. The ENUM Registrant is the billing and administrative contact for the
1409           registered ENUM domain name. This is to simplify the description about who provides what
1410           information.
1411          A corporation provides one or more contact persons to the telephony service provider (TSP)
1412           when subscribing to the telephony service. Only those designated contact persons can subscribe
1413           to ENUM from an ENUM Registrar.
1414          The ENUM Registrant can register many TNs at the same time, but only one TN is described in
1415           the procedures.

1416   8.3.3.2 Proposed Provisioning Procedures
1417   The provisioning procedures are exactly the same as those described in Section 8.3.1.2 when AAA-
1418   related data elements and procedures are not considered. A corporate ENUM Registrant needs to
1419   provide company credit reference information when dealing with the Tier 2 Provider and the ENUM
1420   Registrar.

1421   8.3.4   Corporate Registrant Did Not Select the Tier 2 at Initial ENUM Registration
1422   A corporate ENUM Registrant does not select the Tier 2 Provider before approaching an ENUM
1423   Registrar for ENUM registration. In this scenario, the ENUM Registrar does not support the Tier 2
1424   Provider functions but out sources those functions to a Tier 2 Provider.

1425   8.3.4.1 Assumptions
1426          Same assumptions as are described in section x except that the Corporate ENUM Registrant does
1427           not select the Tier 2 Provider.

1428   8.3.4.2 Proposed Provisioning Procedures
1429   The provisioning procedures are exactly the same as those described in Scenario 8.3.2.2 when AAA-
1430   related data elements and procedures are not considered. A corporate ENUM Registrant needs to
1431   provide company credit reference information when dealing with the ENUM Registrar.

1432   8.3.5 Broker/Agent Involved In Initial ENUM Registration
1433   A broker or agent is authorized by the ENUM Registrant for ENUM registration on behalf of the ENUM
1434   Registrant.

1435   8.3.5.1 Assumptions
1436   The ENUM Registrant authorizes a broker or an agent to register for ENUM on behalf of
1437   himself/herself.

                                                          44
       Tier 1B Technical and Operational Requirements                           CC1 ENUM LLC TAC-08.00001-2005


1438   8.3.5.2 Proposed Provisioning Procedures
1439   In addition to the procedures described in Sections X throughX, the ENUM Registrar or the Tier 2
1440   Provider must validate that the broker/agent is indeed authorized by the ENUM Registrant to register for
1441   ENUM for him/her or to contract with the Tier 2 Provider. The broker or agent is expected to provide a
1442   letter of agency or other proof of their authorization to register the TN on behalf of the assignee.

1443   8.3.6 ENUM Registrant transfers his/her ENUM registration to another ENUM Registrar.
1444   ENUM Registrant transfers his/her ENUM registration to another ENUM Registrar.

1445   8.3.6.1 Assumptions
1446          ENUM Registrant uses the same Tier 2 Provider and the nameservers are the same
1447          ENUM Registrant can initiate the transfer of the ENUM registration at any point during the term
1448           of the registration

1449   8.3.6.2 Proposed Provisioning Procedures
1450   1.      The ENUM Registrant decides to use another ENUM Registrar for his/her ENUM registration and
1451   provides the following information to that ENUM Registrar:
1452          TN
1453          [A list of nameserver host names associated with the ENUM domain name]2
1454          Existing ENUM registration expiration date
1455          [ENUM registration renewal period (e.g., two years)]3
1456          The ENUM Registrant's information and technical, administrative and billing contact information
1457          Any AAA-related information required by the ENUM Registrar
1458   2.      The ENUM Registrar may interact with the ENUM Registrant for more information if needed. The
1459   ENUM Registrar then validates the ENUM Registrant's identity and TN assignment (methodology and procedures
1460   defined in Section XX). The validation may be waived if the ENUM Registrant provides the password associated
1461   with his/her ENUM domain name when the Extensible Provisioning Protocol (EPP) is used between the Tier 1
1462   Registry and the ENUM Registrar. If that is the case, go to Step 3.
1463           a.       If the validation fails, the request for transferring the ENUM registration is rejected. The process
1464           stops for an unauthorized ENUM Registrant. The ENUM Registrant, if the valid TN assignee, either
1465           provides more information to get the rejection reversed and continues with Step 3; or selects another
1466           ENUM Registrar and goes back to Step 1. He/she also may decide not to transfer his/her ENUM
1467           registration.
1468           b.      If the validation is successful, go to Step 3.
1469   3.   ENUM Registrar requests that the Tier 1B Registry transfer the service registration for this particular
1470   ENUM domain name by providing the following information:
1471          Request for transferring an existing ENUM domain name


       2 If the EPP is used, there is no need to provide the list of nameservers because the host information is
       in the to-be-transferred ENUM domain name object.
       3Depending on the Tier 1B Registry’s policy, there may be a default renewal period of one year if the
       renewal period is not provided.

                                                                 45
       Tier 1B Technical and Operational Requirements                         CC1 ENUM LLC TAC-08.00001-2005


1472           ENUM domain name (e.g., 4.3.2.1.3.3.5.2.0.2.1.e164.arpa)
1473           [ENUM Registration renewal period (e.g., two years)]
1474        Any AAA-related information
1475   Please note that the password associated with the ENUM domain name is provided to the Tier 1B Registry if EPP
1476   is used. This ENUM Registrar may also request the transfer of some of the contact objects when needed. The
1477   process would be similar except that a Contact ID instead of the ENUM domain name, and the password
1478   associated with the Contact object instead of the one associated with the ENUM domain name object, are used for
1479   each to-be-transferred Contact object.
1480   4.     After successful authentication and authorization checks of the ENUM Registrar, the Tier 1B Registry
1481   determines whether there is an existing service registration for the ENUM domain name that can be transferred. 4
1482   a.      If YES, it puts the ENUM domain name in the “pending transfer” state and informs the old ENUM
1483   Registrar about the transfer.
1484   i.       If the Tier 1B Registry receives an acknowledgement from the old ENUM Registrar or times out for
1485   receiving an acknowledgement, it completes the transfer (e.g., the new ENUM Registrar is now the sponsoring
1486   Registrar) and changes the state of the ENUM domain name back to the “active” state. The Tier 1B Registry also
1487   notifies the new ENUM Registrar about the successful completion of the transfer request. The notification may be
1488   put in a queue for ENUM Registrars to retrieve.
1489   ii.     If the Tier 1B Registry receives a negative acknowledgement from the old ENUM Registrar, it will deny
1490   the transfer and the old and new ENUM Registrars and the ENUM Registrant will need to resolve this among
1491   themselves.
1492   b.       If NOT, the Tier 1B Registry rejects the transfer by indicating that the ENUM domain name does not
1493   exist.
1494   5.       After receiving the response from the Tier 1B Registry, the ENUM Registrar performs the following:
1495   a.      If the transfer is complete, it puts the information associated with the transferred ENUM domain name in
1496   the local data stores. It informs the ENUM Registrant about the successful transfer and completes the necessary
1497   actions (e.g., collects the registration fee from the ENUM Registrant for the renewal period and pays the Tier 1B
1498   Registry).
1499   b.     If the old ENUM Registrar rejects the transfer, it informs the ENUM Registrant about the result and urges
1500   the ENUM Registrant to settle the matter with the old ENUM Registrar.
1501   c.      If the transfer is rejected due to the non-existence of the ENUM domain name, it informs the ENUM
1502   Registrant about the result.
1503
1504
1505
1506
1507
1508


       4 If the EPP is used and the provided password is correct, the Tier 1B Registry will immediately
       perform the transfer and may not notify the old ENUM Registrar. There will not be any need to
       continue the process below.

                                                              46
       Tier 1B Technical and Operational Requirements        CC1 ENUM LLC TAC-08.00001-2005


1509
1510
1511
1512
1513




                                                        47
       Tier 1B Technical and Operational Requirements                      CC1 ENUM LLC TAC-08.00001-2005


                                                                                Registrant chooses
                                                                                new Registrar and
                                                                                     provides
                                                                                 registration data




                                                                       fails Registrar validates
                                                                             Registrant identity
                                 END         Transfer denied                      and TN
                                                                                assignment
                                                                                            succeed
                                                                                               s
                                                                             Registrar requests
                                                                              Tier 1B Registry
                                                                                   transfer
                                                                                registration


                                                                     no         Tier 1B check for
                                                                                     existing
                                                                                   registration


                                                                                                 yes
                                                                                      Tier 1B puts
                                                                                   registration into
                                                                                “pending” transfer and
                                                                                notifies Old Registrar




                                                Transfer denied;                 Old Registrar
                                                Registrant must                 acknowledgment
                                              resolve with old and
                                                new Registrars

                                                                     negative                    Positive/Timeout
                                                                                                     timeout
                                                                                    Registry
                                                                                   completes
                                                                                transfer; informs
                                                                                  new Registrar


                                                                                  New Registrar
                                                                                  updates local
                                                                                                                END
                                                                                  data; informs
                                                                                   Registrant
1514                                    FIGURE 4 - Flow Chart for 8.3.6.2:
1515                    ENUM Registrant Transfers ENUM Registration to another Registrar

1516   8.3.7        ENUM Registrant Checks/Changes Information at the ENUM Registrar
1517   ENUM Registrant checks or changes information stored at the ENUM Registrar.


                                                          48
       Tier 1B Technical and Operational Requirements                         CC1 ENUM LLC TAC-08.00001-2005


1518   8.3.7.1            Assumptions
1519              The ENUM Registrant has already set up an account with the ENUM Registrar.
1520              The ENUM Registrant can check and make changes to all the information except the Telephone
1521               Number (TN) kept by the ENUM Registrar.
1522              The ENUM Registrant may initiate the OAM&P changes himself/herself, or his/her action may
1523               be triggered by requests from the Tier 2 Provider if the ENUM Registrant is the only one that can
1524               deal with the ENUM Registrar.
1525              Some data changes/additions/deletions made by the ENUM Registrant at the ENUM Registrar
1526               need to be reflected at the Tier 1B Registry. It is assumed that if the ENUM Registrar approves
1527               and acts upon such a request the Tier 1B Registry will not deny that request.

1528   8.3.7.2 Proposed Provisioning Procedures
1529   1. The ENUM Registrant provides the authentication/authorization information and indicates the type of
1530   request with the associated information to the ENUM Registrar. The type of request and associated
1531   information may include:
1532               Check
1533                  1. Status of ENUM domain name registration
1534                  2.All or certain current values associated with the registered ENUM domain name account
1535                    such as:
1536                           Technical, administrative and billing contact information
1537                           Contact information for the account with the ENUM Registrar
1538                           Nameservers
1539                           Registration expiration date
1540               Add
1541                  o New nameserver
1542                  o Additional technical, administrative or billing contact information
1543                  o Additional Contact information for the account with the ENUM Registrar
1544                  o Authorization for the Tier 2 Provider to access its data stored at the ENUM Registrar, if not
1545                    previously authorized
1546               Delete
1547                  o Nameserver
1548                   Technical, administrative or billing contact information
1549                  o Contact information for the account with the ENUM Registrar
1550                  o Authorization of the Tier 2 Provider to access its data stored at the ENUM Registrar, if
1551                    previously authorized
1552               Modify/Change

                                                               49
       Tier 1B Technical and Operational Requirements                      CC1 ENUM LLC TAC-08.00001-2005


1553              o User id, if permitted
1554              o Password
1555              o Partial information (e.g., address, phone number and/or e-mail address) in technical,
1556                administrative or billing contact information
1557              o Partial information (e.g., address) in Registrant's contact information
1558              o Partial information (e.g., address) in Tier 2 Provider contact information
1559              o TSP account information such as the TSP name if ENUM Registrant ports his/her TN to a
1560                new TSP or billing address
1561   2. The ENUM Registrar validates the ENUM Registrant.
1562   3. If the validation fails, the ENUM Registrar rejects the request indicating authentication/authorization
1563      failure (e.g., invalid password). The ENUM Registrant, if valid, needs to resolve the problem (e.g.,
1564      re-assign a password) with the ENUM Registrar and resubmit the request.
1565   If the validation is successful, the ENUM Registrar proceeds with Step 4.
1566   4. The ENUM Registrar checks whether the requested action is valid.
1567        a) If the request is not valid, the ENUM Registrar rejects the request indicating the reason of
1568           rejection. Illegal requests include but are not limited to:
1569              o Change/modify data that the ENUM Registrant is not allowed to change/modify or does not
1570                exist
1571              o Delete data that does not exist or will result in missing mandatory data
1572              o Add data that the ENUM Registrant is not allowed to add or will exceed the maximum
1573                number allowed for that data
1574        b) If the request is valid, the ENUM Registrar performs required actions that include but are not
1575           limited to:
1576              o Returns the requested information, if available, or an indication that the requested
1577                information is not available
1578              o Replaces with data from the request and returns a positive acknowledgement
1579              o Deletes data and returns a positive acknowledgement
1580              o Adds data and returns a positive acknowledgement
1581        If the action of change/deletion/addition cannot be performed due to internal problems, the
1582        Registrar indicates "request pending" to the ENUM Registrant. After successful completion of the
1583        request, the Registrar sends a positive acknowledgement to the ENUM Registrant.
1584        The Registrar may inform the Tier 2 Provider if it is authorized by the ENUM Registrant to
1585        access/change certain data, and the ENUM Registrant has made changes to the data that the Tier 2
1586        Provider is authorized to change.
1587   5. The ENUM Registrar checks whether it needs to inform the Tier 1B Registry about the data change,
1588      deletion or addition, or to access the Tier 1B Registry for data status.



                                                           50
       Tier 1B Technical and Operational Requirements                     CC1 ENUM LLC TAC-08.00001-2005


1589      If the ENUM Registrar need not inform the Tier 1B Registry about the data change, deletion,
1590      addition or to access the Tier 1B Registry for data status, the process stops.
1591      If the ENUM Registrar needs to inform the Tier 1B Registry about the data change, deletion or
1592      addition, it provides the authentication/authorization information and indicates the type of request
1593      with the associated information to the Tier 1B Registry.
1594   6. The Tier 1B Registry validates the ENUM Registrar.
1595      If the validation fails, the Tier B1 Registry rejects the request indicating authentication/authorization
1596      failure (e.g., invalid password). The ENUM Registrar, if valid, needs to resolve the problem (e.g.,
1597      re-assign a password) with the Tier 1B Registry and resubmit the request.
1598      If the validation is successful, the Tier B1 Registry proceeds with Step 7.
1599   7. The Tier 1B Registry checks whether the requested action is valid.
1600      If the request is not valid (e.g., syntax error), the Tier 1B Registry rejects the request indicating the
1601      reason for rejection.
1602      If the request is valid, the Tier 1B Registry performs the required actions and returns a positive
1603      acknowledgement.
1604   8. ENUM Registrar returns the requested information if not yet done in step 4.
1605




                                                           51
       Tier 1B Technical and Operational Requirements                CC1 ENUM LLC TAC-08.00001-2005


                                              Registrant provides
                                                 credentials &
                                              request to Registrar




                                              Registrar validates
                                                 Registrant




                                              Registrar validates
                                               requested action




                                              Registrar executes
                                               requested action




                                      no       Need to inform
                                               Tier B Registry?
                               END


                                                              yes
                                                Registrar sends
                                                   request &
                                                 credentials to
                                                    Tier 1B



                                              Registry validates
                                                 Registrar




                                              Registry validates
                                              requested action




                                               Registry updates
                                                 and returns
                                                                       END
                                              acknowledgement

1606   FIGURE 5 – Flow Chart for 8.3.7.2: ENUM Registrant Checks/Changes Information at ENUM Registrar
1607


                                                         52
       Tier 1B Technical and Operational Requirements                      CC1 ENUM LLC TAC-08.00001-2005


1608   8.3.8     ENUM Registrant Checks/Changes Information at the Tier 2 Provider
1609   The ENUM Registrant checks or changes information stored at the Tier 2 Provider.

1610   8.3.8.1          Assumptions
1611            The ENUM Registrant has already set up an account with the Tier 2 Provider.
1612            If the ENUM Registrant did not select the Tier 2 Provider at the ENUM registration, it
1613             approaches the ENUM Registrar as if it is the Tier 2 Provider.
1614            The ENUM Registrant can check and make changes to all the information kept by the Tier 2
1615             Provider; however, the ENUM Registrant is not likely to change his/her Telephone Number (TN)
1616             or ENUM domain name.
1617            The ENUM Registrant may initiate the OAM&P changes himself/herself, or his/her action may
1618             be triggered by requests from an ASP if the ENUM Registrant is the only one that can interact
1619             with the Tier 2 Provider.
1620            No data change/addition/deletion made by the ENUM Registrant at the Tier 2 Provider needs to
1621             be reflected at the ENUM Registrar or the Tier 1B Registry.

1622   8.3.8.2          Proposed Provisioning Procedures
1623       1. If the ENUM Registrant did not select the Tier 2 Provider during ENUM registration, go to Step
1624          4.
1625             Otherwise, the ENUM Registrant provides the authentication/authorization information and
1626             indicates the type of request with the associated information to the Tier 2 Provider. The type of
1627             request and associated information may include:
1628       o Check all or certain current values associated with the ENUM Registrant account such as:
1629                o Contact information
1630                o Information in NAPTR RRs
1631                o Authorized ASP list, and data each ASP can access/modify
1632                o Credit card information, if applicable
1633       o Add
1634                o NAPTR RR
1635                o Additional Contact information for the account with the Tier 2 Provider
1636                o Authorization of an ASP to access its data stored at the Tier 2 Provider, if not previously
1637                  authorized
1638       o Delete
1639                o Contact information for the account with the Tier 2 Provider
1640                o NAPTR RR
1641                o Authorization of an ASP to access its data stored at the Tier 2 Provider, if previously
1642                  authorized
1643       o Modify/Change
                                                            53
       Tier 1B Technical and Operational Requirements                     CC1 ENUM LLC TAC-08.00001-2005


1644             o User id, if permitted
1645             o Password
1646             o Partial information (e.g., address, phone number and/or e-mail address) in ENUM
1647               Registrant's contact information
1648             o Partial information in NAPTR (e.g., preference value, URL)
1649             o Partial information (e.g., address) in ASP contact information
1650             o List of data that an ASP can access/modify
1651      2. The Tier 2 Provider validates the ENUM Registrant.
1652          If the validation fails, the Tier 2 Provider rejects the request indicating
1653          authentication/authorization failure (e.g., invalid password). The process stops here for an
1654          invalid ENUM Registrant. The ENUM Registrant, if valid, needs to resolve the problem (e.g.,
1655          re-assign a password) with the Tier 2 Provider and resubmit the request by returning to Step 1.
1656          If the validation is successful, the Tier 2 Provider proceeds with Step 3.
1657      3. The Tier 2 Provider checks whether the requested action is valid.
1658          If the request is not valid, the Tier 2 Provider rejects the request indicating the reason of
1659          rejection. Illegal requests include but are not limited to:
1660             o Change/modify data that does not exist
1661             o Delete data that does not exist or will result in missing mandatory data
1662             o Add data that the ENUM Registrant is not allowed to add or will exceed the maximum
1663               number allowed for that data
1664          If the request is valid, the Tier 2 Provider performs required actions that include but are not
1665          limited to:
1666             o Return the requested information
1667             o Replace with data from the request and return a positive acknowledgement
1668             o Delete data and return a positive acknowledgement
1669             o Add data and return a positive acknowledgement
1670          If the action of change/deletion/addition cannot be preformed due to internal problems, the
1671          Registrar indicates "request pending" to the ENUM Registrant. After successful completion of
1672          the request, the Registrar sends a positive acknowledgement to the ENUM Registrant.
1673          It may inform an ASP, if it is authorized by the ENUM Registrant, to access/change certain data
1674          and the ENUM Registrant has made changes to the data that the ASP is authorized to change.
1675   The process stops.
1676      4. The ENUM Registrant provides the authentication/authorization information and indicates the
1677         type of request with the associated information to the ENUM Registrar. The type of request and
1678         associated information are the same as those described in Step 1.
1679      5. The ENUM Registrar validates the ENUM Registrant.


                                                           54
       Tier 1B Technical and Operational Requirements                   CC1 ENUM LLC TAC-08.00001-2005


1680          If the validation fails, the ENUM Registrar rejects the request indicating
1681          authentication/authorization failure (e.g., invalid password). The process stops here for an
1682          invalid ENUM Registrant. The ENUM Registrant, if valid, needs to resolve the problem (e.g.,
1683          re-assign a password) with the ENUM Registrar and resubmit the request by going back to Step
1684          4.
1685          If the validation is successful, the ENUM Registrar proceeds with Step 6.
1686      6. If the ENUM Registrar out sources the Tier 2 Provider operation to a third-party, go to Step 7.
1687         Otherwise, the ENUM Registrar checks whether the requested action is valid.
1688             a. If the request is not valid, the ENUM Registrar rejects the request indicating the reason
1689                for rejection. Illegal requests include but are not limited to:
1690             o Change/modified data that does not exist
1691             o Delete data that does not exist or will result in missing mandatory data
1692             o Add data that the ENUM Registrant is not allowed to add or will exceed the maximum
1693               number allowed for that data
1694             b) If the request is valid, the ENUM Registrar performs required actions that include but are
1695                not limited to:
1696             o Return the requested information
1697             o Replace with data from the request and return a positive acknowledgement
1698             o Delete data and return a positive acknowledgement
1699             o Add data and return a positive acknowledgement
1700          If the action of change/deletion/addition cannot be preformed due to internal problems, the
1701          Registrar indicates "request pending" to the ENUM Registrant. After successful completion of
1702          the request, the Registrar sends a positive acknowledgement to the ENUM Registrant.
1703          The Registrar may inform an ASP if it is authorized by the ENUM Registrant to access/change
1704          certain data and the ENUM Registrant has made changes to the data that the ASP is authorized to
1705          change.
1706   The process stops.
1707      7. The ENUM Registrar relays the request to the Tier 2 Provider, which performs the same
1708         procedures as stated in Step 6, except that the response is relayed through the ENUM Registrar.
1709         If for any reason the ENUM Registrar cannot relay the response to the ENUM Registrant, either
1710         the Tier 2 Provider or the ENUM Registrar




                                                         55
       Tier 1B Technical and Operational Requirements                            CC1 ENUM LLC TAC-08.00001-2005


                      Registrant                                                      Registrant
                       provides                                                        provides
                     credentials &                                                   credentials &
                   request to Tier 2                                                  request to
                                                                                       Registrar


                       Tier 2 validates                                           Registrar validates
                         Registrant                                                  Registrant




                  yes                                                                         yes
                    Tier 2 validates                   Registrar relays    yes      Registrar out
                   requested action                    request to Tier 2           sources Tier 2?




                 yes                                                                            no
                    Tier 2 executes                                               Registrar validates
                   requested action                                                requested action




                                                                                  Registrar executes
                           END                                                     requested action
                                                                                                            END



1711                          a. Registrant selected Tier2                   b. Registrar selected Tier 2
1712     FIGURE 6 – Flow Chart for 8.3.8.2: ENUM Registrant Checks/Changes Information at Tier 2 Provider
1713   may re-transmit the response for a certain time period depending on who detects the failure.

1714   8.3.9 ENUM Registrar Checks/Changes Information at Tier 1B Registry
1715   The ENUM Registrar checks or changes information stored at the Tier 1B Registry.

1716   8.3.9.1              Assumptions
1717            Only the checks/changes initiated by the ENUM Registrar are discussed. Checks/changes
1718             initiated by the ENUM Registrant and the Tier 2 Providers may be accomplished through the
1719             Registrar.
1720            The ENUM Registrar does not initiate a transfer request without the ENUM Registrant’s request

1721   8.3.9.2         Proposed Provisioning Procedures
1722   1. The ENUM Registrar provides the AAA-related information and indicates the type of request with the
1723   associated information to the Tier 1B Registry. Any information that is provided by this ENUM Registrar can be
1724   checked and changed by this ENUM Registrar. An ENUM Registrar may check some information (e.g., whether

                                                                   56
       Tier 1B Technical and Operational Requirements                           CC1 ENUM LLC TAC-08.00001-2005


1725   an ENUM domain name is available) even if the information is provided by other ENUM Registrars. The type of
1726   request and associated information may include:
1727         Check
1728              o    All or certain current information associated with the ENUM Registrant’s ENUM registration
1729                   such as:
1730                          Contact information
1731                          service registration expiration date
1732                          The last date when an object is created, modified or transferred
1733                          State of an object (e.g., active, server hold)
1734              o    All or certain current information associated with the ENUM Registrar’s data such as:
1735                          Contact information
1736                          Organizational information
1737                          IP address(es)
1738                          [Web site address]
1739                          [WHOIS server name]
1740                          Security pass phrase (for authenticating an ENUM Registrar when contacting the Tier 1
1741                           Registry’s customer support by telephone)
1742                          User id and password information
1743              o    Digital certificate information
1744         Add
1745              o    Additional ENUM Registrar Contact information
1746              o    Additional ENUM Registrar Organizational information
1747              o    Additional IP address(es)
1748              o    Additional user id and password
1749         Delete
1750                          Contact information
1751                          IP address(es)
1752                          Credit card and/or bank information
1753                          User id and password, when there are multiple accounts
1754         Modify/Change
1755                          Partial information (e.g., address, phone number and/or email address) in ENUM
1756                           Registrar’s contact information
1757                          Partial information in ENUM Registrar’s such as contact information, user id, password,
1758                           security pass phrase, digital certificate information, web site address and ContactInfo
1759                           server name
1760   2. The Tier 1B Registry validates the ENUM Registrar.



                                                                57
       Tier 1B Technical and Operational Requirements                               CC1 ENUM LLC TAC-08.00001-2005


1761             a. If the validation fails, the Tier 1B Registry rejects the request indicating authentication/authorization
1762             failure (e.g., invalid password). The ENUM Registrar, if valid, needs to resolve the problem (e.g., re-
1763             assign a password) with the Tier 1B Registry and resubmit the request.
1764             b. If the validation is successful, the Tier 1B Registry proceeds with Step 3.
1765   3.        The Tier 1B Registry checks whether the requested action is valid.
1766             a.      If the request is not valid (e.g., syntax error), the Tier 1B Registry rejects the request indicating
1767             the reason for rejection.
1768             b.     If the request is valid, the Tier 1B Registry performs the required actions and returns a positive
1769             acknowledgement.
1770   4.        When a response is received, the ENUM Registrar performs the following:
1771             a.      If the request is rejected, it tries to determine the cause of the failure and re-submit the request, if
1772             needed, after the problem is cleared.
1773   b.        If the request is accepted, it makes the necessary changes/additions/ deletions in the local data stores.

                                                           Registrar provides
                                                             credentials &
                                                           request to Tier 1B



                                                            Tier 1B Registry
                                                           validates Registrar


                                                                        YES
                                                           Registry validates
                                                           requested action


                                                                        YES
                                                           Registry executes
                                                            requested action
                                                               and returns
                                                           acknowledgement


                                                           Registrar updates
                                                           local data stores




                                                                 END

1774        FIGURE 7 – Flow Chart for 8.3.9.2: ENUM Registrar Checks/Changes Information at Tier 1B Registry




                                                                   58
       Tier 1B Technical and Operational Requirements                               CC1 ENUM LLC TAC-08.00001-2005


1775    8.3.10        ENUM Registrant Renews ENUM Registration
1776   The ENUM Registrant renews his/her ENUM registration when the previous ENUM registration is to expire or
1777   when he/she decides to extend the service registration period at any time before the existing service registration
1778   expires.

1779   8.3.10.1            Assumptions
1780                       o The ENUM Registrant does not change the ENUM Registrar for the renewed
1781                         registration period.
1782                       o Host information associated with the ENUM domain name does not change.
1783                       o The ENUM Registrant will renew the service contract, if necessary, with the Tier 2
1784                         Provider. This process is not discussed.

1785   8.3.10.2        Proposed Provisioning Procedures
1786       1. The ENUM Registrant requests that the ENUM Registrar renew or extend the existing ENUM registration
1787       by providing the following information:
1788                  ENUM TN
1789                  Renewal period (e.g., two years)
1790            Any AAA-related information required by the ENUM Registrar for renewal.
1791       2. The ENUM Registrar then validates the ENUM Registrant's identity and the TN assignment as defined in
1792       Section xx.
1793              a.      If the validation fails, the application for renewing the ENUM registration is rejected. The
1794              process stops for an unauthorized ENUM Registrant. The ENUM Registrant if the valid TN assignee
1795              provides more information to have the rejection reversed and continues with Step 3. He/she also may
1796              decide not to renew the ENUM registration.
1797       b. If the validation is successful, the ENUM Registrar proceeds with Step 3.
1798       3. The ENUM Registrar requests that the Tier 1B Registry renew the ENUM domain name by providing the
1799       following information:
1800                  Request to renew ENUM registration.
1801                  ENUM domain name (e.g., 4.3.2.1.3.3.5.2.0.2.1.e164.arpa).
1802                  Renewed ENUM Registration period (e.g., two years).
1803            Any AAA-related information required by the Tier 1B Registry.
1804       4. After successful authentication and authorization checks of the ENUM Registrar, the Tier 1B Registry
1805       determines whether there is an existing ENUM registration for the requested ENUM domain name.
1806              a.      If YES and the ENUM Registrar is the one who registered the ENUM domain name, the Tier 1B
1807              Registry acknowledges to the ENUM Registrar that the ENUM domain name registration is renewed with
1808              a new registration expiration date. The Tier 1B Registry then updates the data (e.g., new registration
1809              expiration date and date when renewal is done) in the local data stores.
1810              b.       Otherwise, the Tier 1B Registry rejects the request. This case is not likely to happen.
1811       5. After receiving the response from the Tier 1B Registry, the ENUM Registrar performs the following:
1812              a.      If the renewal is accepted, it updates information such as the service registration expiration date
1813              and the date the renewal is done in the local data stores. It informs the ENUM Registrant about the
1814              successful renewal and completes the necessary actions (e.g., collects the registration fee from the ENUM
1815              Registrant for the renewal period and pays the Tier 1B Registry).
                                                                   59
       Tier 1B Technical and Operational Requirements                         CC1 ENUM LLC TAC-08.00001-2005


1816          b.   If the renewal is rejected due to the non-existence of the ENUM domain name, it informs the
1817          ENUM Registrant about the result.


                                                                           Registrant
                                                                       requests Registrar
                                                                       renew registration



                                      Request rejected                  Registrar validates
                                                               fails     Registrant identity
                          END                                           and TN assignment


                                                                                       succeeds
                                                                       Registrar requests
                                                                        Tier 1B Registry
                                                                             renew



                                                                             Tier 1B
                                                      fails               authenticates
                                                                             request

                                                                                       succeeds
                                                                       Registry checks for
                                                          no                 existing
                                                                       registration for TN

                                                                                        yes
                                                                          Tier 1 renews
                                                                         registration and
                                                                              sends
                                                                        acknowledgement


                                                                       Registrar updates
                                                                          local data and
                                                                       informs Registrant




                                                                              END

1818
1819             FIGURE 8 – Flow Chart for 8.3.10.2: ENUM Registrant Renews ENUM Registration
1820

1821   8.3.11 ENUM Registrant Terminates ENUM Registration
1822   The ENUM Registrant terminates his/her ENUM registration before the previous ENUM registration
1823   expires.
                                                          60
       Tier 1B Technical and Operational Requirements                       CC1 ENUM LLC TAC-08.00001-2005


1824   8.3.11.1           Assumptions
1825             The ENUM registration is to be terminated before the registration expiration date.

1826   8.3.11.2           Proposed Provisioning Procedures
1827       1. The ENUM Registrant contacts the ENUM Registrar and indicates his/her desire to terminate
1828          registration for his/her ENUM domain name. The ENUM Registrant provides the following
1829          information:
1830                     ENUM TN
1831                     Request for terminating ENUM registration
1832                     Any AAA-related information required by the ENUM Registrar
1833       2. The ENUM Registrar checks if the request (see Section XX for detailed procedures) comes from
1834          the authorized ENUM Registrant.
1835                      If YES, the ENUM Registrar reminds the ENUM Registrant that terminating his/her
1836                      ENUM registration may cause associated addresses and services to no longer function as
1837                      before. Proceed to step 3.
1838                      If NO, the ENUM Registrar ends the termination process by indicating to the requester
1839                      that he/she is not authorized to terminate the service registration for the subject ENUM
1840                      domain name.
1841       3. The ENUM Registrar notifies the Tier 1B Registry about service termination by providing the
1842          following information:
1843                 ENUM domain name
1844                 Request for terminating ENUM
1845                 Any AAA-related information required by the Tier 1B Registry
1846       4. The Tier 1B Registry notifies the ENUM Registrar that the registration for the subject ENUM
1847          domain name has been terminated. It then removes the ENUM registration for that ENUM
1848          domain name from its local data store and nameservers.
1849       5. The ENUM Registrar acknowledges the successful execution of the request to the ENUM
1850          Registrant.
1851       6. The responsible party arranges for removal of NAPTR records at the Tier 2 Provider:
1852              If the ENUM Registrar also provides the Tier 2 Provider function it removes the NAPTR records
1853              from its nameservers.
1854              If the ENUM Registrar uses a Tier 2 Provider, it notifies the Tier 2 Provider to terminate the
1855              service by removing the NAPTR records from its nameservers.
1856              If the ENUM Registrant had contracted for the Tier 2 Provider function directly, the ENUM
1857              Registrant notifies the Tier 2 Provider to terminate the service by removing the NAPTR records
1858              from its nameservers.
1859              If the ENUM Registrant provided the Tier 2 Provider function him/her/itself, the Registrant
1860              removes the NAPTR records from his/her/its nameservers.

                                                             61
       Tier 1B Technical and Operational Requirements              CC1 ENUM LLC TAC-08.00001-2005


1861      7. Notification of Application Service Providers (ASPs). The Registrant should notify the
1862         Registrant’s ASPs that the ENUM registration has been terminated if they are authorized to
1863         access/change the data at the Tier 2 Provider.
1864
1865




                                                        62
       Tier 1B Technical and Operational Requirements                            CC1 ENUM LLC TAC-08.00001-2005



                                                                         Registrant
                                                                          requests
                                                                       termination of
                                                                        registration



                                  Request rejected           fails       Registrar
                                                                       authenticates
                      END
                                                                          request

                                                                                    succeed
                                                                                       s
                                                                      Registrar requests
                                                                       Tier 1B Registry
                                                                           terminate
                                                                          registration



                                                                          Tier 1B
                                                                       authenticates
                                                     fails
                                                                          request

                                                                                    succeed
                                                                                       s
                                                                   Registry checks
                                                               no     for existing
                                                                  registration for TN

                                                                                 yes
                                                                     Tier 1B deletes TN
                                                                      from NS & local
                                                                       DB and sends
                                                                     acknowledgement


                                                                      Registrar updates
                                                                        local data and
                                                                     informs Registrant



                                                                      Tier 2 provider,
                                                                      ASPs notified by
                                                                        Registrar or
                                                                        Registrant



                                                                       Tier 2 deletes
                                                                         NAPTRs
                                                                                               END


1866       FIGURE 9 – Flow Chart for 8.3.11.2: ENUM Registrant Terminates ENUM Registration
1867

                                                             63
       Tier 1B Technical and Operational Requirements                            CC1 ENUM LLC TAC-08.00001-2005


1868   8.3.12 ENUM Registrant No Longer a TN Assignee
1869   The ENUM Registrant terminates his/her telephone service before the previous ENUM registration expires, which
1870   may result in a dangling registration.

1871   8.3.12.1          Assumptions
1872      The ENUM Registrant does not inform the ENUM Registrar that he/she is no longer the TN
1873       assignee.
1874      The ENUM Registrar detects that the ENUM Registrant is no longer the TN assignee through the
1875       periodic re-validations or notification from the ENUM Registrant’s serving Telephony Service
1876       Provider (TSP).5

1877   8.3.12.2           Proposed Provisioning Procedures
1878              1.      The ENUM Registrar determines that the registration of an ENUM domain name should be
1879              terminated; it requests the Tier 1 Registry to delete the ENUM domain name by providing the following
1880              information:
1881                 o   Request to delete the ENUM registration.
1882                 o   ENUM domain name (e.g., 4.3.2.1.3.3.5.2.0.2.1.e164.arpa)
1883                 o    Any AAA-related information required by the Tier 1B Registry.
1884              2.      After successful authentication and authorization checks of the ENUM Registrar, the Tier 1B
1885              Registry determines whether there is an existing ENUM registration for the requested ENUM domain
1886              name.6
1887                     a.      If YES, the Tier B1 Registry acknowledges to the ENUM Registrar that the ENUM
1888                     domain name registration is deleted. The Tier 1B Registry then removes information associated
1889                     with the ENUM domain name in the local data stores and updates the zone file.
1890                     b.      If NOT, the Tier 1B Registry rejects the request. This case is not likely to happen.
1891              3.      After receiving the response from the Tier 1B Registry, the ENUM Registrar performs the
1892              following:
1893                     a.      If the deletion is accepted, it removes information associated with the ENUM domain
1894                     name in the local data stores. It may inform the ENUM Registrant about the termination of
1895                     his/her ENUM domain name registration and the technical contacts associated with the ENUM
1896                     domain name via e-mails about removal of the NAPTR RRs from the nameservers.
1897                     b.     If the deletion is rejected due to non-existence of the ENUM domain name, it removes
1898                     information associated with the ENUM domain name in the local data stores.
1899
1900




       5The ENUM Registrar may need to make contractual arrangements with the TSP to receive the
       notification.
       6 If the EPP is used between the Tier 1B Registry and the ENUM Registrar, the ENUM Registrar may
       request to delete some of the Contact objects and/or Host objects.

                                                                 64
       Tier 1B Technical and Operational Requirements                            CC1 ENUM LLC TAC-08.00001-2005


                                                                             ENUM Registrar
                                                                                determines
                                                                            registration should
                                                                              be terminated



                                                                            Registrar requests
                                                                             Tier 1B Registry
                                                                                 terminate
                                                                                registration



                                             Request rejected                       Tier 1B
                                 END
                                                                                 authenticates
                                                                                    request


                                                                         fails              succeed
                                                                                               s
                                                                           Registry checks for
                                                                           existing registration
                                                                                  for TN


                                                                                                 succeed
                                                                                                    s
                                                                            Tier 1B deletes TN
                                                                           from NS & local DB
                                                                                and sends
                                                                            acknowledgement



                                                                             Registrar deletes
                                                                             registration from
                                                                               local data and
                                                                            informs Registrant




                                                                                    END


1901
1902               FIGURE 10: Flow Chart for 8.3.12.2: ENUM Registrant No Longer a TN Assignee
1903

1904   8.3.13 ENUM Registrar Terminates the ENUM Registration
1905   The ENUM Registrar terminates the ENUM Registrant’s service registration before the previous ENUM
1906   registration expires due to contractual business reasons. This can happen when the ENUM Registrant does not
1907   pay the ENUM Registrar the registration fee before the grace period of the ENUM registration (e.g., five days)
1908   expires. It may also happen if the ENUM Registrar determines that an ENUM registration is no longer valid (e.g.,
1909   as the result of the dispute resolution process).



                                                             65
       Tier 1B Technical and Operational Requirements                          CC1 ENUM LLC TAC-08.00001-2005


1910   8.3.13.1          Assumptions
1911   This ENUM Registrar has registered the subject ENUM domain name.

1912   8.3.13.2       Proposed Provisioning Procedures
1913   The provisioning procedures are exactly the same as those described in Section XX.

1914   8.3.14         Tier 1B Registry Terminates the ENUM Registration
1915   The Tier 1 Registry determines that the registration of an ENUM domain name should be terminated.

1916   8.3.14.1         Assumptions
1917   The ENUM Registrant does not renew the service registration for his/her ENUM domain name and the grace
1918   period for renewal has expired, or the Tier 1B Registry is informed that an ENUM registration is invalid (e.g., via
1919   the dispute resolution process or a court order).

1920   8.3.14.2           Proposed Provisioning Procedures
1921              1.      The Tier 1B Registry determines that the registration of an ENUM domain name should be
1922              terminated; it removes information associated with the ENUM domain name in the local data stores and
1923              updates the zone file and notifies the associated Registrar.
1924              2.     The Tier 1B Registry may inform the technical contacts via e-mails associated with the ENUM
1925              domain name to remove the NAPTR RRs from the nameservers.

1926   8.4               Area Code Split
1927   An area code is split; the new area code is assigned to the same Tier 1B Registry that handles the old
1928   area code.

1929   8.4.1             Assumptions
1930             The Tier 1B Registry that handles the old area code is given the new area code when an area
1931              code split happens.
1932             The Tier 1B Registry, the ENUM Registrars and the Tier 2 Providers that are involved with the
1933              telephone numbers (TNs) impacted by the area code split will take the necessary steps to support
1934              the area code split and the permissive dialing period7 whether the ENUM Registrant informs
1935              them about the area code split/TN change or not.
1936             The ENUM domain name that is associated with the TN under the old area code is referred to as
1937              the "old ENUM domain name." The ENUM domain name that is associated with the TN under
1938              the new area code is referred to as the "new ENUM domain name." For example, if the TN 703-
1939              434-1234 has registered for ENUM and is to be changed to 571-434-1234, the old ENUM
1940              domain name would be "4.3.2.1.4.3.4.3.0.7.1.e164.arpa," and the new ENUM domain name
1941              would be "4.3.2.1.4.3.4.1.7.5.1.e164.arpa." The TN under the old area code (e.g., 703-434-1234)


       7 The permissive dialing period is the interval during which the TN under either the old area code or
       the new area code can be dialed to reach the same termination. The length of the permissive dialing
       period is normally a few months and is set by the state Public Utility Commission for each involved
       area code.


                                                               66
       Tier 1B Technical and Operational Requirements                      CC1 ENUM LLC TAC-08.00001-2005


1942             is referred to as the "old TN," and the TN under the new area code (e.g., 571-434-1234) is
1943             referred to as the "new TN."
1944            Only the ENUM domain names that are associated with the TNs impacted by the area code split
1945             (those that are to be changed to the new area code) are discussed. ENUM domain names that are
1946             not impacted by the area code split are handled by the usual procedures. For example, if 703-
1947             538-6789 is not subject to the area code change, its associated ENUM domain name,
1948             9.8.7.6.8.3.5.3.0.7.1.e164.arpa, will remain the same.
1949            T1 is the time (e.g., 12:01am EST on 6/1/01) when the new area code (e.g., 434 split from the
1950             old area code 804) becomes effective and the permissive dialing period begins. T2 is the time
1951             (e.g., 12:01am EST on 1/15/02) when the permissive dialing period ends.
1952            Normally an area code split involves only the area code change; however, it may happen that
1953             both the area code and the office code of a TN are changed. When an area code change is
1954             mentioned in this document, it also covers the case when both the area code and the office code
1955             are changed.
1956             In very rare cases, an area code split may be done based on a geographical boundary (e.g., a
1957             country line), which may result in a situation of "partitioned NPA-NXX." Some TNs in an
1958             NPA-NXX are changed to the new area code, while others remain in the old area code. Further
1959             study will determine how specific TNs under a partitioned NPA+NXX code can be obtained
1960             from telephony service providers (TSPs) since only the serving TSP of a TN knows whether that
1961             TN is impacted by the area code split. It may also be possible, although this is unlikely, to
1962             directly verify with the ENUM Registrant whether his/her TN is impacted by the area code split.
1963            The North American Numbering Plan Administrator (NANPA) (http://www.nanpa.com) offers
1964             free notifications of area code splits; however, the information reflects the affected NPA-NXX
1965             codes at the notification time. Because NPA-NXX codes can be added or deleted, there is a need
1966             to know the updated information. Affected NPA-NXX codes for a particular area code split can
1967             be found in the "area code split exchange diskette" from Telcordia (http://www.trainfo.com).

1968   8.4.2            Proposed Provisioning Procedures

1969   8.4.2.1          Procedures/Guidelines for a Tier 1B Registry with a Permissive Dialing Period

1970   The Tier 1B Registry is informed that it is to handle the new area code due to an area code split, and
1971   notified of the T1 and T2 that are associated with the permissive dialing period. If the same Tier 1B
1972   Registry always handles the old and new area codes for an area code split, it shall monitor the
1973   announcements about the area code splits.
1974   One week before T1, it is recommended that the Tier 1B Registry send an e-mail message to each
1975   associated ENUM Registrar about the area code split and to remind it to take the appropriate actions
1976   required by the area code split.
1977   At no time before the T1 shall the Tier 1B Registry accept any request on any new ENUM domain name
1978   from the ENUM Registrar. This is because the new TN under the new area code is not yet effective
1979   before T1.
1980   Starting at T1, the Tier 1B Registry shall be capable of accepting and responding to any request made on
1981   the new ENUM domain name from the ENUM Registrar, and shall perform data updates on the local
1982   data stores and zone files, if applicable.
                                                            67
       Tier 1B Technical and Operational Requirements                        CC1 ENUM LLC TAC-08.00001-2005


1983   The Tier 1B Registry shall not accept any request on any old ENUM domain name from the ENUM
1984   Registrar during the permissive dialing period.
1985   At T1, the Tier 1B Registry shall perform zone file updates to add all the new ENUM domain names.
1986   One, or more than one, new zone files may be created, or new data is added, to the existing zone file for
1987   those new ENUM domain names with exactly the same nameserver information copied from those
1988   associated with the corresponding old ENUM domain names at T1.8 The Tier 1B Registry shall not
1989   remove the Nameserver (NS) RRs associated with the old ENUM domain names from the existing zone
1990   file(s).
1991   The Tier 1B Registry should adhere to the following guidelines in setting the Time to Live (TTL)9
1992   values for the NS RRs associated with the old ENUM domain name, or for the minimum TTL in the
1993   Start of a zone of Authority (SOA) RR, if that minimum TTL is the default TTL value for all the RRs in
1994   the same zone.
1995            Set the TTL to a value between a day and a week in the beginning and before the last month of
1996             the permissive dialing period.
1997            Set the TTL to a value between an hour and a day in the last month but before the last week of
1998             the permissive dialing period.
1999            Set the TTL to a value between ten minutes and an hour in the last week but before the last day
2000             of the permissive dialing period.
2001            Set the TTL to ten minutes in the last day of the permissive dialing period.
2002   The TTL in the NS RRs associated with the new ENUM domain name is set to a typical value (e.g.,
2003   from a day to a week) depending on the Tier 1B Registry policy (e.g., frequency of zone file updates).
2004   Within twenty-four hours after T1, the Tier 1B Registry shall update its stored information to reflect the
2005   area code change on all the TNs. It shall search the local data stores and change all the TNs that are
2006   subject to the area code change, not just those that are associated with the old ENUM domain names.
2007   This will change all the phone numbers and fax numbers in the contact information of all the records.
2008   The Tier 1B Registry shall not accept any request (e.g., create, check, update, renew or transfer) on any
2009   old ENUM domain name during the permissive dialing period while it maintains records associated with
2010   the old ENUM domain name.
2011   The Tier 1B Registry shall keep the nameserver information in the zone file, and information in the local
2012   data stores associated with each new ENUM domain name, synchronized with those associated with the
2013   corresponding old ENUM domain name during the permissive dialing period. Any update request on
2014   the new ENUM domain name that is received from the ENUM Registrar during the permissive dialing
2015   period shall cause the same update on the old ENUM domain name. This includes the data in the
2016   WHOIS database in case there are inquires about the ContactInfo information on the old ENUM domain
2017   names. Because of this need for data synchronization, it is highly recommended that the same Tier 1B
2018   Registry handle both the old and new area codes when there is an area code split.



       8 The new and old ENUM domain names may or may not be in the same zone file depending on how
       the zones are cut/delegated.
       9   TTL is a time limit on how long a received RR can be kept in a cache.

                                                             68
       Tier 1B Technical and Operational Requirements                      CC1 ENUM LLC TAC-08.00001-2005


2019   During the permissive dialing period, if the Tier 1B Registry receives a create request for an ENUM
2020   domain name that is available (e.g., no record exists for this ENUM domain name) and the associated
2021   TN is a new TN due to an area code split, it shall create a record for the old ENUM domain name in
2022   addition to the record for the new ENUM domain name.
2023   At T2, the Tier 1B Registry shall perform zone file updates to remove the NS RRs associated with the
2024   old ENUM domain names. It shall remove all the records associated with the old ENUM domain names
2025   from the local data stores.
2026   After the permissive dialing period expires, the Tier 1B Registry shall expect new ENUM registrations
2027   on the old ENUM domain names because the associated TNs can be reassigned to new telephony
2028   subscribers.
2029   Within twenty-four hours after T2, the Tier 1B Registry should send an e-mail message to each technical
2030   contact and ENUM Registrant that is associated with each old ENUM domain name to remind them to
2031   update the zone file(s) by removing any RR in the zone file and the data in the local data stores that is
2032   associated with the old ENUM domain name.

2033   8.4.3          Procedures/Guidelines for a Tier 1B Registry without a Permissive Dialing Period
2034   Since there is no permissive dialing period, T1 and T2 are the same. T1 in this case is the time when the
2035   new TN must be dialed and the old TN must not be dialed.
2036   The Tier 1B Registry is informed that it is to handle the new area code due to area code split and T1
2037   when mandatory dialing starts. If the same Tier 1B Registry always handles the old and new area codes
2038   for an area code split, it shall monitor the announcements about the area code splits.
2039   One week before T1, it is recommended that the Tier 1B Registry send an e-mail message to each
2040   associated ENUM Registrar about the area code split and to remind them to take the appropriate actions
2041   required by the area code split.
2042   At no time before T1 shall the Tier 1B Registry accept any request on any new ENUM domain name
2043   from the ENUM Registrar. This is because the new TN under the new area code is not yet effective
2044   before T1.
2045   The Tier 1B Registry should adhere to the following guidelines in setting the Time to Live (TTL) values
2046   for the NS RRs associated with the old ENUM domain name, or for the minimum TTL in the Start of a
2047   zone of Authority (SOA) RR, if that minimum TTL is the default TTL value for all the RRs in the same
2048   zone.
2049          Set the TTL to a value between a day and a week when more than a month before T1.
2050          Set the TTL to a value between an hour and a day when less than a month but more than a week
2051           before T1.
2052          Set the TTL to a value between ten minutes and an hour when less than a week but more than a
2053           day before T1.
2054          Set the TTL to ten minutes within the last day before T1.
2055   At T1, the Tier 1B Registry shall perform zone file updates to change all the old ENUM domain names
2056   to the new ENUM domain names while keeping the nameserver information unchanged. This can also
2057   be done by adding the NS RRs for the new ENUM domain names and removing those associated with
2058   the old ENUM domain names when dynamic updates are done. The TTL in the NS RRs associated with

                                                          69
       Tier 1B Technical and Operational Requirements                    CC1 ENUM LLC TAC-08.00001-2005


2059   the new ENUM domain names should be set to a typical value (e.g., from a day to a week) depending on
2060   the Tier 1 Registry policy (e.g., frequency of zone file updates).
2061   Starting at T1, the Tier 1B Registry shall be capable of accepting and responding to any request made on
2062   the new ENUM domain name from the ENUM Registrar and shall perform data updates on the local
2063   data stores and zone files, if applicable.
2064   Within twenty-four (24) hours after T1, the Tier 1B Registry shall update its stored information to
2065   reflect the area code change on all the TNs. It shall search the local data stores and change all the TNs
2066   that are subject to the area code change, not just those that are associated with the old ENUM domain
2067   names. This will change all the phone numbers and fax numbers in the contact information of all the
2068   records.
2069   After T1, the Tier 1B Registry shall expect new ENUM registrations on the TNs under the old area code
2070   because the associated TNs can be reassigned to new telephony subscribers.

2071   8.4.4   Procedures/Guidelines for an ENUM Registrar with a Permissive Dialing Period
2072   The ENUM Registrar should be aware of any area code split and the associated T1 and T2 that impacts
2073   the ENUM domain names registered through it. The Tier 1B Registry will notify Registrars of
2074   impending area code splits.
2075   One week before T1, it is recommended that the ENUM Registrar inform the ENUM Registrant, based
2076   on the Registrant contact information, about the changes of the ENUM domain name and the contacts'
2077   phone numbers and/or fax numbers for each old ENUM domain name. If it has the technical contact
2078   information or if it deals with the Tier 2 Provider, the ENUM Registrar should send an e-mail message
2079   to each technical contact or the contact person of the Tier 2 Provider to remind him/her to update the
2080   zone file(s) by adding the NS RRs and the Naming Authority Pointer (NAPTR) RRs for the new ENUM
2081   domain name before T1 and to leave the NS RRs and the NAPTR RRs associated with the old ENUM
2082   domain names in the existing zone file(s) until the permissive dialing period expires.
2083   At no time before T1 may the ENUM Registrar accept any request on any new ENUM domain name
2084   from the ENUM Registrant, nor shall they submit any request on any new ENUM domain name to the
2085   Tier 1B Registry.10
2086   Within twenty-four hours after T1, the ENUM Registrar shall update its stored information to reflect the
2087   area code change on all the TNs. It shall search the databases and change any TN that is subject to the
2088   area code change. This will change all the phone numbers and fax numbers in the contact information in
2089   all the records.
2090   It is recommended that the ENUM Registrar verify with the ENUM Registrant, or the Tier 2 Provider if
2091   it is allowed to access/update data, whether a telephone number is correct when it receives a request
2092   during the permissive dialing period to add a phone or fax number or to change to a phone or fax
2093   number that is in a NPA-NXX subject to an area code change due to an area code split.
2094   Starting at T1, the ENUM Registrar shall be capable of accepting and responding to any request made
2095   on the new ENUM domain name from the ENUM Registrant, and shall perform data updates on the
2096   local data stores and the Tier 1B Registry, if applicable.


        The ENUM Registrar could accept the requests and wait until T1 to submit the requests to the Tier 1B
       10

       Registry, or it could submit the requests using the old ENUM domain names before T1.

                                                          70
       Tier 1B Technical and Operational Requirements                   CC1 ENUM LLC TAC-08.00001-2005


2097   The ENUM Registrar shall stop accepting any request on any old ENUM domain name during the
2098   permissive dialing period. If the ENUM Registrar receives any request on the old ENUM domain name
2099   from the ENUM Registrant during the permissive dialing period, it should inform the ENUM Registrant
2100   about the change to the new ENUM domain name due to an area code split. It shall also inform the
2101   ENUM Registrant and/or the technical contact to have the NAPTR RRs that are associated with both the
2102   new and old ENUM domain names in the Tier 2 Provider's nameservers.
2103   During the permissive dialing period, if the ENUM Registrar receives a new registration for an ENUM
2104   domain name that is available (e.g., no record exists for this ENUM domain name) and the associated
2105   TN is a new TN due to an area code split, it shall submit a create request on the new ENUM domain
2106   name and shall inform the ENUM Registrant and/or the technical contact to have the NAPTR RRs that
2107   are associated with both the new and old ENUM domain names in the Tier 2 Provider's nameservers.
2108   The ENUM Registrant may inform the ENUM Registrar about the TN change whether it is related to the
2109   ENUM domain name or any phone or fax number. The ENUM Registrar can confirm/ignore the update
2110   request if the change has been made automatically and may double check whether the change has been
2111   made correctly.
2112   After the permissive dialing period expires, the ENUM Registrar shall expect new ENUM registrations
2113   on the old ENUM domain names because the associated TNs can be reassigned to new telephony
2114   subscribers.
2115   Within twenty-four hours after T2, the ENUM Registrar should send an e-mail to each technical contact
2116   and ENUM Registrant that are associated with each old ENUM domain name to remind them to update
2117   the zone file(s) by removing any RR in the zone file and the data in the local data stores that are
2118   associated with the old ENUM domain name.
2119

2120   8.4.5         Procedures/Guidelines for an ENUM Registrar without a Permissive Dialing Period
2121   The ENUM Registrar should be aware of any area code split and the associated T1 that impacts the
2122   ENUM domain names registered through it. The Tier 1B Registry will notify Registrars of impending
2123   area code splits.
2124   One week before T1, it is recommended that the ENUM Registrar inform the ENUM Registrant, based
2125   on the Registrant contact information, about the changes of the ENUM domain name and the contacts'
2126   phone numbers and/or fax numbers for each old ENUM domain name. If it has the technical contact
2127   information or if it deals with the Tier 2 Provider, the ENUM Registrar should send an e-mail message
2128   to each technical contact or the contact person of the Tier 2 Provider to remind him/her to update the
2129   zone file(s) by adding the NS RRs and the NAPTR RRs for the new ENUM domain name, and by
2130   removing those RRs associated with the old ENUM domain name at T1.
2131   At no time before T1 may the ENUM Registrar accept any request on any new ENUM domain name
2132   from the ENUM Registrant; nor shall they submit any request on any new ENUM domain name to the
2133   Tier 1B Registry.
2134   Within five minutes after T1, the ENUM Registrar shall update its stored information to reflect the area
2135   code change on all the TNs. It shall search the databases and change any TN that is subject to the area
2136   code change. This will change all the phone numbers and fax numbers in the contact information in all
2137   the records.


                                                         71
       Tier 1B Technical and Operational Requirements                    CC1 ENUM LLC TAC-08.00001-2005


2138   It is recommended that the ENUM Registrar verify with the ENUM Registrant, or a Tier 2 Provider if it
2139   is allowed to access/update data, whether a telephone number is correct when it receives a request within
2140   one month after T1 to add a phone or fax number or to make a change to a phone or fax number that is
2141   in a NPA+NXX subjecting to an area code change due to area code split.
2142   Starting at T1, the ENUM Registrar shall be capable of accepting and responding to any request made
2143   on the new ENUM domain name from the ENUM Registrant, and shall perform data updates on the
2144   local data stores and the Tier 1B Registry, if applicable.
2145   The ENUM Registrant may inform the ENUM Registrar about the TN change whether it is related to the
2146   ENUM domain name or any phone or fax number before or after T1. The ENUM Registrar can
2147   confirm/ignore the update request if the change has been made automatically and may double check
2148   whether the change has been made correctly.
2149   After T1, the ENUM Registrar shall expect new ENUM registrations on the old ENUM domain names
2150   because the associated TNs can be reassigned to new telephony subscribers.

2151   8.4.6          Procedures/Guidelines for a Tier 2 Provider with a Permissive Dialing Period
2152   The Tier 2 Provider should be aware of any area code split that impacts the ENUM domain names for
2153   which it currently hosts the NAPTR RRs and the associated T1 and T2. The Registrars will notify Tier
2154   2 Providers of impending area code splits.
2155   At any time within a week before T1, it is recommended that the Tier 2 Provider inform the ENUM
2156   Registrant and Application Service Providers (ASPs), if the ASPs are allowed to update data, that are
2157   associated with each old ENUM domain name it currently serves to remind him/her/them that it will
2158   automatically update the ENUM domain name and any affected contact information after T1 due to the
2159   area code change.
2160   At no time before T1 may the Tier 2 Provider accept any request (e.g., create, update or delete) on any
2161   new ENUM domain name from the ENUM Registrant.11
2162   Starting at T1, the Tier 2 Provider shall be capable of accepting and responding to any request made on
2163   the new ENUM domain name from the ENUM Registrant and shall perform data updates on the local
2164   data stores and zone files, if applicable.
2165   During the permissive dialing period, if the Tier 2 Provider receives a request for an ENUM domain
2166   name that has not been provisioned (e.g., no record exists for this ENUM domain name) and the
2167   associated TN is a new TN due to an area code split, it shall create the NAPTR RRs for both the new
2168   and old ENUM domain names.
2169   The Tier 2 Provider shall continue accepting requests on the old ENUM domain names until T1. During
2170   the permissive dialing period, the Tier 2 Provider shall stop accepting any request on any old ENUM
2171   domain name from the ENUM Registrant or any Application Service Provider (ASP), if the ASP is
2172   allowed to update data. If the Tier 2 Provider receives any request on the old ENUM domain name from


       11The Tier 2 Provider could accept the requests and wait until T1 to act on them, or it could act on the
       old ENUM domain names before T1. But if records or zone file(s) have been created for the new
       ENUM domain name, the Tier 2 Provider may act upon them before T1. In that case, any update on the
       data for the new ENUM domain name shall cause the same update on the data for the old ENUM
       domain name before T1.

                                                          72
       Tier 1B Technical and Operational Requirements                   CC1 ENUM LLC TAC-08.00001-2005


2173   the ENUM Registrant or an ASP during the permissive dialing period, it should inform the ENUM
2174   Registrant or ASP about the change to the new ENUM domain name due to an area code split.
2175   It is recommended that the Tier 2 Provider verify with the ENUM Registrant, or an ASP if it is allowed
2176   to access/update data, whether a telephone number is correct when it receives a request during the
2177   permissive dialing period to add a phone or fax number or to make a change to a phone or fax number
2178   that is in a NPA-NXX subjecting to an area code change due to an area code split.
2179   Before T1, the Tier 2 Provider shall have the NS RRs and the NAPTR RRs associated with the new
2180   ENUM domain names added to the zone file(s). The information in the RRs for the new ENUM domain
2181   name, except for the owner or domain name shall be exactly the same as that in the RRs for the old
2182   ENUM domain name. It is recommended that this be done in the last day at least an hour earlier than
2183   T1.
2184   During the permissive dialing period, if the Tier 2 Provider receives a create request for an ENUM
2185   domain name that is available (e.g., no record exists for this ENUM domain name) and the associated
2186   TN is a new TN due to an area code split, it shall create a record for the old ENUM domain name in
2187   addition to the record for the new ENUM domain name.
2188   The Tier 2 Provider has the choice of either of the following two schemes in handling the RRs
2189   associated with the old and new ENUM domain names in the zone file(s):
2190         Maintain the same NS RRs and NAPTR RR information, except for the "owner" or the "domain
2191          name," for the old ENUM domain name during the permissive dialing period.
2192          The Tier 2 Provider shall keep the NS RRs and NAPTR RRs in the zone file and any data in the
2193          local data stores (e.g., WHOIS) that are associated with the old ENUM domain name
2194          synchronized with those associated with the new ENUM domain name. Any change to the data
2195          associated with the new ENUM domain name during the permissive dialing period will cause the
2196          same change to the data associated with the old ENUM domain name.
2197         Use only one Canonical Name (CNAME) RR for the old ENUM domain name (e.g.,
2198          4.3.2.1.4.3.4.3.0.7.1.e164.arpa) that identifies the canonical name of an alias, which is the new
2199          ENUM domain name (e.g., 4.3.2.1.4.3.4.1.7.5.1.e164.arpa).
2200          Using this scheme, any update to the zone file related to the new ENUM domain name will not
2201          require any update to the zone file related to the old ENUM domain name; however, updates to
2202          the data in the local data stores (e.g., Contactinfo data) will still be required.
2203          It is highly recommended that the zone files that contain the CNAME RR for the old ENUM
2204          domain name and the NS RRs and NAPTR RRs for the new ENUM domain name, if different,
2205          are on the same nameserver so that the nameserver can respond to a query for the old ENUM
2206          domain name with the CNAME RR and the NAPTR RRs in the same response. If the zone files
2207          are not on the same nameserver the Tier 2 Provider will return the CNAME RR and the ENUM
2208          client will have to generate a new query for the new ENUM domain name, if it does not have the
2209          information cached, causing additional delay in the DNS resolution process.
2210   The Tier 2 Provider should adhere to the following guidelines in setting the TTL values for the CNAME
2211   RRs, or for the NS RRs and NAPTR RRs associated with the old ENUM domain name, or for the
2212   minimum TTL in the SOA RR if that minimum TTL is the default TTL value for all the RRs in the same
2213   zone.


                                                         73
       Tier 1B Technical and Operational Requirements                      CC1 ENUM LLC TAC-08.00001-2005


2214          Set the TTL to a value between a day and a week in the beginning and before the last month of
2215           the permissive dialing period.
2216          Set the TTL to a value between an hour and a day in the last month but before the last week of
2217           the permissive dialing period.
2218          Set the TTL to a value between ten minutes and an hour in the last week but before the last day
2219           of the permissive dialing period.
2220          Set the TTL to ten minutes in the last day of the permissive dialing period.
2221   Within twenty-four hours after T1, the Tier 2 Provider shall update its stored information to reflect the
2222   area code change on all the TNs. It shall search the local data stores and change all the TNs that are
2223   subject to the area code change. This will change all the phone numbers and fax numbers in the contact
2224   information of all the records.
2225   The ENUM Registrant may inform the Tier 2 Provider about the TN change whether it is related to the
2226   ENUM domain name or any phone or fax number. The Tier 2 Provider can confirm/ignore the update
2227   request if the change has been made automatically and/or double check whether the change has been
2228   made correctly.
2229   At T2, The Tier 2 Provider shall perform zone file updates to remove all the CNAME RRs or the NS
2230   RRs and NAPTR RRs associated with the old ENUM domain names. It shall remove all data related to
2231   the old ENUM domain names from the local data stores.
2232   After the permissive dialing period expires, the Tier 2 Provider shall expect new service requests on the
2233   old ENUM domain names because the associated TNs can be reassigned to new telephony subscribers.

2234   8.4.7          Procedures/Guidelines for the Tier 2 Provider without a Permissive Dialing Period
2235   The Tier 2 Provider should be aware of any area code split that impacts the ENUM domain names for
2236   which it currently hosts the NAPTR RRs and the associated T1. The Registrar will notify Tier 2
2237   Providers of impending area code splits.
2238   At any time within a week before T1, it is recommended that the Tier 2 Provider inform the ENUM
2239   Registrant and ASPs, if the ASPs are allowed to update data, that are associated with each old ENUM
2240   domain name it currently serves to remind him/her/them that it will automatically update the ENUM
2241   domain name and any affected contact information after T1 due to the area code change.
2242   The Tier 2 Provider should adhere to the following guidelines in setting the Time to Live (TTL) values
2243   for the NS RRs and NAPTR RRs associated with the old ENUM domain name, or for the minimum
2244   TTL in the Start of a zone of Authority (SOA) RR, if that minimum TTL is the default TTL value for all
2245   the RRs in the same zone.
2246          Set the TTL to a value between a day and a week when more than a month before T1.
2247          Set the TTL to a value between an hour and a day when less than a month but more than a week
2248           before T1.
2249          Set the TTL to a value between ten minutes and an hour when less than a week but more than a
2250           day before T1.
2251          Set the TTL to ten minutes within the last day before T1.


                                                           74
       Tier 1B Technical and Operational Requirements                     CC1 ENUM LLC TAC-08.00001-2005


2252   At no time before T1 may the Tier 2 Provider accept any request (e.g., create, update or delete) on any
2253   new ENUM domain name from the ENUM Registrant.
2254   At T1, the Tier 2 Provider shall perform zone file updates to change all the old ENUM domain names to
2255   the new ENUM domain names while keeping the nameserver (NS) information and other NAPTR RR
2256   information unchanged. This can also be done by adding the NS and NAPTR RRs for the new ENUM
2257   domain names and removing those associated with the old ENUM domain names when dynamic updates
2258   are done. The TTL in the NS RRs and NAPTR RRs associated with the new ENUM domain names
2259   should be set to typical values (e.g., from a day to a week) depending on the Tier 2 Provider policy (e.g.,
2260   frequency of zone file updates).
2261   At T1 or later, the Tier 2 Provider shall be capable of accepting and responding to any request made on
2262   the new ENUM domain name from the ENUM Registrant or an ASP, and shall perform data updates on
2263   the local data stores and zone files, if applicable.
2264   Within five minutes after T1, the Tier 2 Provider shall update its stored information to reflect the area
2265   code change on all the TNs. It shall search the local data stores and change all the TNs that are subject
2266   to the area code change, not just those that are associated with the old ENUM domain names. This will
2267   change all the phone numbers and fax numbers in the contact information of all the records.
2268   After T1, the Tier 2 Provider shall expect new ENUM registrations on the old ENUM domain names
2269   because the associated TNs can be reassigned to new telephony subscribers. However, it is
2270   recommended that within one month after T1 the Tier 2 Provider verify with the ENUM Registrant or
2271   ASP to see whether it is still using the old ENUM domain name or old TNs when receiving requests that
2272   are related to the old ENUM domain names or that contain old TN(s).

2273   8.5     Data Elements for ENUM Registration
2274   This Section identifies the data elements that the ENUM Registrars provide to the Tier 1B Registry at
2275   the time of initial ENUM registration. The first list of data elements are those that are related to the
2276   initial ENUM registration and are independent of the protocol used between the Tier 1B Registry and
2277   the ENUM Registrar. The second list is of the data structures that may be needed if the Extensible
2278   Provisioning Protocol (EPP) is used between the Tier 1B Registry and ENUM Registrars. Some data
2279   elements contain several information elements. Optional data elements or information elements are
2280   shown in brackets12 (e.g., [Organization]). Please note that subject to the ENUM Tier 1B Registry
2281   policies, additional data elements may be required and some optional data elements may become
2282   mandatory and vice versa. Data elements required for authorization, authentication and accounting with
2283   an ENUM Registrar, and for secure communications between ENUM Registrars and the Tier 1B
2284   Registry, are not addressed

2285   8.5.1    Typical Data Elements Related to ENUM Registration
2286   The data elements provided to the Tier 1B Registry are listed below. Immediately following are
2287   explanations on how those data elements may be used by the Tier 1B Registry. Information in brackets
2288   (e.g., [Organization]) is optional.




       12Optional data elements are based on draft-ietf-provreg-epp-domain-04.txt, draft-ietf-provreg-epp-
       host-04.txt and draft-ietf-provreg-epp-contact-04.txt.

                                                           75
       Tier 1B Technical and Operational Requirements                          CC1 ENUM LLC TAC-08.00001-2005


2289            ENUM domain name (e.g., 4.3.2.1.3.3.5.2.0.2.1.e164.arpa). This data element needs to be in the
2290             zone file of the Tier 1B Registry's nameservers for DNS resolution.
2291            Two to thirteen fully qualified domain names for hosts/nameservers (e.g., the host names such as
2292             ns1.foo.biz).13 Those domain names need to be in the zone file of the Tier 1B Registry's
2293             nameservers for DNS resolution.
2294            [ENUM Registration period] (e.g., two years).14 This data element is needed to indicate to the
2295             Tier 1B Registry the period that a particular ENUM domain name registration is in effect
2296             (assuming maintenance of the underlying number assignment of ENUM Registrant).
2297            ENUM Registrant's contact information. This data element may be used for data escrow (e.g.,
2298             the Tier 1B Registry can inform the ENUM Registrant to transfer to another ENUM Registrar in
2299             case his/her serving ENUM Registrar goes out of business) and in dispute resolution.
2300             Contact information consists of at least one but not more than two instances of the postal
2301             information below.15 The postal information can be completely in American Standard Code for
2302             Information Interchange (ASCII) encoding; completely in Unicode Transformation Format -8
2303             (UTF-8) encoding; or one each when there are two postal records.
2304                    Name or role/title
2305                    [Organization]
2306                    Address ([street], city, [state/province], [zip code/postal code] and country code)16
2307                    [Phone number and extension, if any]
2308                    [Fax number]
2309                    E-mail address
2310            Billing contact information (at least one but not more than two). This data element may be
2311             needed for data escrow (e.g., an ENUM Registrar uses the Tier 1B Registry as a backup in case
2312             of database failure).
2313             At least one but not more than two of the postal elements below can be used for Billing Contact
2314             Information. The postal information can be all in ASCII encoding, or all in UTF-8 encoding, or
2315             one each when there are two postal records.


       13 It is yet to be determined whether only one nameserver is allowed for ENUM Registrants who
       operate the Tier 2 Provider functions themselves (e.g., in the basement). Also, the IP addresses that are
       associated with the nameservers are not needed because no nameserver will be under the registered
       1.e164.arpa zone.
       14   This data element is optional if a default registration period is specified.
       15The initial purpose of allowing up to two postal records is to show one postal record in ASCII
       encoding so that everyone can understand, and the other postal record, if needed, in UTF-8 encoding of
       native language. The rule does not restrict postal information to be all in ASCII or UTF-8 encoding.
       16The ENUM Registrant may have a postal address outside the U.S.. For example, U.S. embassies
       outside the U.S. may have +1 telephone numbers assigned to them (e.g., U.S. government is assigned a
       unique area code).

                                                               76
       Tier 1B Technical and Operational Requirements                    CC1 ENUM LLC TAC-08.00001-2005


2316                Name or role/title
2317                [Organization]
2318                Address([street], city, [state/province],[zip code/postal code] & country code)
2319                [Phone number and extension, if any]
2320                [Fax number]
2321                E-mail address
2322         Administrative contact information (at least one but not more than two). This data element may
2323          be needed for data escrow (e.g., an ENUM Registrar uses the Tier 1B Registry as a backup in
2324          case of database failure) and dispute resolution.
2325          At least one but not more than two of the postal elements below can be used for Administrative
2326          Contact Information. The postal information can be all in ASCII encoding, or all in UTF-8
2327          encoding, or one each when there are two postal records.
2328                Name or role/title
2329                [Organization]
2330                Address ([street], city, [state/province], [zip code/postal code] and country code)
2331                [Phone number and extension, if any]
2332                [Fax number]
2333                E-mail address
2334         Technical contact information (at least one but not more than two). This data element may be
2335          needed for data escrow and trouble shooting (e.g., in case the Tier 1B Registry needs to discuss
2336          technical issues associated with an ENUM domain name but the serving ENUM Registrar is not
2337          available).
2338          At least one but not more than two of the postal elements below can be used for Technical
2339          Contact Information. The postal information can be all in ASCII encoding, or all in UTF-8
2340          encoding, or one each when there are two postal records.
2341                Name or role/title
2342                [Organization]
2343                Address ([street], city, [state/province], [zip code/postal code] and country code)
2344                [Phone number and extension, if any]
2345                [Fax number]
2346                E-mail address
2347   The mandatory and optional data elements or information elements in some of the data elements shown
2348   above are based on the EPP-related Internet-Drafts mentioned in footnote #12. "Mandatory"
2349   information elements must be provided and "optional" information elements may or may not be
2350   provided to the Tier 1B Registry.


                                                          77
       Tier 1B Technical and Operational Requirements                         CC1 ENUM LLC TAC-08.00001-2005


2351   8.5.2   Object-Management Related Data Elements
2352   This section describes the data structures that are to be provided to the Tier 1B Registry in support of the
2353   EPP being used between the Tier 1B Registry and ENUM Registrars. The EPP is an application layer
2354   client-server protocol for the provisioning and management of objects stored in a Shared Registration
2355   System (SRS). When the EPP is used between an ENUM Registrar and the Tier 1B Registry, the
2356   ENUM Registrar must have the "contact" object(s) and "host" (for nameserver) object(s) created, if they
2357   have not yet been created at the Tier 1B Registry, before they can create the "domain" object that must
2358   refer to those already created "contact" and "host" objects by their "contact IDs" and "host names" for
2359   the registered ENUM domain name.
2360   For each to-be-created "contact," or "domain" object, the ENUM Registrar must provide an
2361   "authorization" data element, which usually is a password, 17 to the Tier 1B Registry.           The
2362   "authorization" data element is used when the ENUM Registrar performs the transfer of a "contact" or
2363   "domain" object. In addition to the "authorization" data element, a "contact ID" data element that is
2364   chosen by the ENUM Registrant or ENUM Registrar and is unique within the Tier 1 Registry is also
2365   provided to the Tier 1B Registry for each to-be-created "contact" object.
2366   To transfer a "domain" object, the new ENUM Registrar provides the domain name and the associated
2367   "authorization" data element to the Tier 1B Registry. To transfer a "contact" object, the new ENUM
2368   Registrar provides the "contact ID" and the associated "authorization" data element to the Tier 1B
2369   Registry. The ENUM Registrant needs to get the "contact ID" and the "authorization" information from
2370   the old ENUM Registrar and give the information to the new ENUM Registrar to submit a transfer
2371   request for that particular "contact" object.
2372   Each "contact," "host" or "domain" object has a list of "status" values that can be set by the ENUM
2373   Registrar and/or the Tier 1B Registry.
2374   For each "domain" object "sponsored" or "owned" by an ENUM Registrar, this ENUM Registrar can set
2375   the status values to prohibit itself from performing update, transfer, delete and/or renew and/or put the
2376   object "on hold," when needed. For each "host" object, the sponsoring ENUM Registrar can set the
2377   status values to prohibit itself from performing update, and/or delete. For each "contact" object, the
2378   sponsoring ENUM Registrar can set the status values to prohibit itself from performing update, transfer
2379   and/or delete.
2380   When creating a "domain" object, this "domain" object can be associated with the "host" objects that are
2381   the nameservers for this "domain" object, and with the "contact" objects where each associated "contact"
2382   object is given a type such as "technical contact" or "billing contact." A "host" object cannot be
2383   transferred and can only be updated by the ENUM Registrar that sponsors or owns it. Only the
2384   "sponsoring" ENUM Registrar can delete a "host" object; however, it cannot delete the object if the
2385   object is associated with another "domain" object.
2386   Those objects are described and discussed here because they are created by ENUM Registrars at the time of initial
2387   ENUM registration.
2388




        Mechanisms other than a password can be used for authorization. Data elements for each of those
       17

       mechanisms can be defined when specific mechanisms are adopted for ENUM provisioning.

                                                              78
       Tier 1B Technical and Operational Requirements        CC1 ENUM LLC TAC-08.00001-2005


2389   SECTION 9.0          DISPUTE RESOLUTION
2390
2391




                                                        79
       Tier 1B Technical and Operational Requirements                            CC1 ENUM LLC TAC-08.00001-2005


2392   Document Issues List:
2393   5-25-05
2394      Bidders need to address how they will comply with privacy and other regulations (ContactInfo) where they
2395       either store the data or if required where the data is originated. Example – CA privacy regulations differ from
2396       other states.
2397      System ready date – for vendor implementation timeline end point, and will also be the start of the Beta
2398       period, which will need to be determined in order to identify commercial start date.
2399      Turn up testing timeline / requirements for registrars and integration into system ready timeline process
2400      Need to have vendor notified that they need to prepare and be compliant with future relevant standards and
2401       national legal/regulatory obligations. When new standard published, vendor needs to notify LLC and present
2402       and implementation plan within 30 days of that notification.
2403      Need to specify / outline future system change management process for bidder
2404      Need agreement technical details developed for the following:
2405             Tier 1A Registry – CC1 ENUM LLC Agreement
2406             Tier 1B Registry US portions of the NANP – CC1 ENUM LLC Agreement for the US
2407             Tier 1B Registry all other NANP Countries – Party to be determined by each NANP country
2408             Tier 1B Registry – ENUM Registrar’s Agreement (Defined by contracting entity and embodied in an
2409             agreement)
2410
2411      Need clear statement that Tier 1B can not function also as a registrar.
2412      Tier 1B will develop the registrar accreditation and registrar agreement process, subject to the approval of the
2413       ENUM LLC and the appropriate regulatory authority.
2414
2415   6-9-05
2416   Editors Note: Need to specify all Agreements and their Title – this is not necessarily and all inclusive list:
2417             Tier 1A Registry – CC1 ENUM LLC Agreement
2418             Tier 1B Registry US portions of the NANP – CC1 ENUM LLC Agreement for the US
2419             Tier 1B Registry all other NANP Countries – Party to be determined by each NANP country
2420             Tier 1B Registry – ENUM Registrar’s Agreement (Defined by contracting entity and embodied in an
2421             agreement)
2422   [Infrastructure ENUM issues are TBD].
2423   Editor’s Note: Need contributions on Registry Database and SRS sections to clarify functionality and
2424   requirements
2425   (Editor’s Note – bidders to respond with details on physical facilities that will be provided to support
2426   SLR’s)
2427   (Editors Note: Physical location of the Tier 1B facilities must be within a NANP member country’s
2428   borders.)



                                                                80
       Tier 1B Technical and Operational Requirements                     CC1 ENUM LLC TAC-08.00001-2005


2429   Editor’s Note: Need to address Geographic and network diversity requirements and tie it to SLRs.
2430   Network diversity is more important that geographic distribution.
2431   Acton Item: Effective dates for registrations (thick registry model) Need information on the effective
2432   end date, start stop dates or what is the length of registration period
2433   Transaction Signatures (TSIG), as described in RFC 2845, will be used for any/all data transmission between
2434   ENUM Tier 1B Registry and Tier 2 nameservers. (Note need to ensure TSIG is addressed in new provisioning
2435   section)
2436
2437
2438




                                                           81

				
DOCUMENT INFO
Categories:
Tags:
Stats:
views:9
posted:6/2/2012
language:
pages:86