Docstoc

Technical and Operational Requirements for an ENUM Tier 1B

Document Sample
Technical and Operational Requirements for an ENUM Tier 1B Powered By Docstoc
					                                                                                                       V-13.00001-2005
                                                                                                     September 23, 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-12.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
                                    Kevin McCandless      Verisign




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


Table of Contents
Abstract ....................................................................................................................................................... i
Foreword .................................................................................................................................................... ii
Table of Figures......................................................................................................................................... v
Table of Tables .......................................................................................................................................... v
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 .......................................................................... 2
   3.1         Definitions .............................................................................................................................................................. 2
   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.4         Zone Data ............................................................................................................................................................. 10
   5.5         ContactInfo........................................................................................................................................................... 10
   554.1       Introduction.......................................................................................................................................................... 11
   5.5.2       Need for ContactInfo Databases ....................................................................................................................... 11
   554.3       Background ........................................................................................................................................................... 11
   5.5.4       General ContactInfo Requirements................................................................................................................... 11
   5.4.6       Privacy Considerations ...................................................................................................................................... 15
   5.4.7       Recommendation ................................................................................................................................................. 15
   5.4.8       Escrow Requirement ............................................................................................................................................ 15
   5.5         Security (Section replaced with revised text) .................................................................................................. 15
   5.5.6       Backup Security ................................................................................................................................................... 18
   5.5.7       Security Audit and Reporting ............................................................................................................................ 18
   5.6         Customer Service Personnel ............................................................................................................................... 18
   5.7         Caching Requirements ........................................................................................................................................ 18
   5.8         System Turn-Up and Testing ............................................................................................................................. 18
   5.10        Operations and Maintenance ............................................................................................................................ 19
   5.11        System Outage Prevention and Recovery ........................................................................................................ 19

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


  5.11.1    System Recovery Procedures.............................................................................................................................. 19
  5.11.2    Database Escrow and Backup ........................................................................................................................... 20
  5.12      Technical and Other Support ............................................................................................................................. 20
  5.13      Other Responsibilities of the Tier 1B Registry ............................................................................................... 21
  5.14      Transition ............................................................................................................................................................. 21
  5.15      Accommodation of Future Internet Architectural Enhancements ................................................................ 21
Section 6.0              Service Level Requirements (SLR) ........................................................................... 21
  6.1       Performance Specifications ................................................................................................................................ 21
  6.2       Service Availability............................................................................................................................................. 21
  6.3       Service Availability - SRS .................................................................................................................................. 22
  6.4       Planned Outage ................................................................................................................................................... 22
  6.5       Extended Planned Outage .................................................................................................................................. 23
  6.6       Processing Time ................................................................................................................................................... 24
  6.7       Cross-Network Nameserver Performance Requirements............................................................................... 25
  6.8       Responsibilities of the Parties ........................................................................................................................... 26
  6.9       Connectivity (with Service Providers) ............................................................................................................. 29
  6.10      Performance and Capacity ................................................................................................................................. 30
  6.11      ENUM Tier 1B Registry Performance Specifications ..................................................................................... 30
  6.12      ENUM Tier 1B Registry Management .............................................................................................................. 33
  6.12.1    Reports and Files ................................................................................................................................................. 33
Section 7.0 Registry-registrar Interface Requirements ..................................................................... 34
  7.1       Shared Registration System (SRS) .................................................................................................................... 34
  7.2       Interfaces between ENUM Tier 1A Registry and Tier 1B Registry ............................................................... 35
  7.3       Interfaces between ENUM Tier 1B and ENUM Registrars ............................................................................ 36
  7.4       Interfaces between ENUM Tier 1B and Tier 2 Registries ............................................................................... 36
Section 8.0          Provisioning (Section replaced with revised text) ....................................................... 36
  8.1       Assumptions ......................................................................................................................................................... 36
  8.2       Provisioning Requirements ................................................................................................................................ 37
  8.3       Provisioning Procedures ..................................................................................................................................... 38
Section 9.0           Dispute Resolution ......................................................................................................... 62




                                                                                      iv
Tier 1B Technical and Operational Requirements                                             CC1 ENUM LLC TAC-12.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-12.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 ITU-T
7    E.164 international numbering standard, and may be accepted or modified by other NANP member nations when
8    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 such,
19   it describes, among other things, the reference architecture for the ENUM Tier 1B Registry.. It also provides the
20   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 is
22   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   SECTION 2.0 REFERENCES
31   The following references contain provisions which, through reference in this text, constitute provisions of this
32   technical requirement. At the time of publication, the editions indicated were valid. All documents are subject to
33   revision, and parties to agreements based on this specification are encouraged to investigate the possibility of
34   applying the most recent editions of the references indicated below.
35   [1] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
36   [2] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC 954, October 1985.
                                                             1
     Tier 1B Technical and Operational Requirements                   CC1 ENUM LLC TAC-12.00001-2005


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

73   SECTION 3.0 DEFINITIONS, ACRONYMS, & ABBREVIATIONS
74   [ed. Need to be placed in alphabetical order]
75   [ed. Fonts need to match]
76
77   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 Tier 1B nameservers and observing the responses from the
                                 Tier 1B nameservers. (These strings of requests and responses
                                 are referred to as a "CNNP Test".)


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


             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.

78

             Registry Database:   a database comprised of data about one or more DNS domain names
                                  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

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


                         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.
        Editor’s Note –     Is an extraordinary and identifiable event beyond the control of
        need to align title
        with definition     Registry Operator affecting the Internet services to be measured
                             pursuant to SLR’s. Such events include but are not limited to
        External Service     congestion, collapse, partitioning, power grid failures, and
        Failure
                             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.
        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.
                                                       4
     Tier 1B Technical and Operational Requirements                                 CC1 ENUM LLC TAC-12.00001-2005


                                   (RFC3912)


             Priority Levels       Need definition for Section 6.0

79
80   3.2    Acronyms & Abbreviations
81   [ed. Table width needs to match above]
82
           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                Fully Qualified Domain Name
           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                Internet Registry Information Service
           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
           NPA                 Numbering Plan Area
           NS                  Name Server
           OAM&P               Operations Administration Maintenance and Provisioning
           PoP                 Point of Presence
           RFC                 Request for Comments
           RIPE NCC            Réseaux IP Européens Network Coordination Centre


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


             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


83    SECTION 4.0             INTRODUCTION
84    This section specifies the reference architecture of a single common ENUM DNS domain, 1.e164.arpa, within
85    Country Code 1.
86    ENUM implementation is based on a tiered architecture as shown in Figure 1. At Tier 0 is the RIPE NCC which
87    maintains the e164.arpa zone.1 Entries in the RIPE NCC nameservers correspond to country codes and point to the
88    name servers of the Tier 1 Registry that is the authoritative nameserver for that country code. Entries in Tier 1
89    Registries normally correspond to individual telephone numbers and point to the Tier 2 nameservers which hold the
90    NAPTR records used to provide actual communication services.
91    Because Country Code 1 corresponds to an integrated numbering plan in which the country code is shared among
92    several countries, the plan of the LLC is to split Tier 1 functionality into a Tier 1A, which would receive the CC1
93    delegation from the Tier 0, and potentially multiple Tier 1Bs serving different CC1 (NANP) member countries.
94    Entries in Tier 1 A will correspond to NPAs and will point to the Tier 1B that holds per –number delegations for the
95    numbers within the given NPA.
96    Tier 1 B Registries are required to deal directly with the CC1 ENUM Tier 1A Registry to arrange for the
97    provisioning of NS records for the NPAs they serve into the CC1 ENUM Tier 1A Registry.
 98   CC1 ENUM Tier1B registry(ies) will be required to establish a business relationship with the CC1 ENUM Tier 1A
 99   Registry prior to registering any NPA in e164.arpa. The nature of the business relationship will be defined by the
100   CC1 ENUM LLC embodied in a Registry agreement, and will be the same for all CC1 ENUM Tier1B registry(ies).
101   This is necessary to ensure that each CC1 ENUM Tier1B registry’s records are properly maintained and that only
102   the assignee of the NPA which has been designated to participate in ENUM by the national administration in charge
103   of the NPA in question can register it into Tier 1A.


      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-12.00001-2005


104   ENUM Registrars, the entities that accept registration requests from number assignees, will, in turn, be required to
105   establish a business relationship with the CC1 ENUM Tier1B registry(ies) prior to registering any telephone
106   number, in e164.arpa.
107   The nature of the business relationship between the Tier 1B and the ENUM registrars will be defined by the
108   contracting entity, embodied in a Registry-Registrar agreement, and will be the same for all ENUM Registrars for a
109   given NPA entered into Tier 1A. This is necessary to ensure competitive equity between registrars in Tier1B and to
110   ensure that ENUM Registrant’s records are properly maintained and that the assignee of the E.164 telephone
111   number has decided to participate in ENUM. Entries in the Tier 1B nameservers point to the nameservers of the
112   Tier 2 provider for a given E.164 number. The Tier 2 Provider for an E.164 number maintains the actual NAPTR
113   records that contain URI’s (Uniform Resource Identifiers) for specific communication services, and the Application
114   Service Provider (ASP) uses these records to provide those services to the number assignee (Registrant)
115
116   Editor’s Note: Corrected Figure 1 below can be pasted from Tier 1a doc – labels fixed there




                                                               7
      Tier 1B Technical and Operational Requirements                           CC1 ENUM LLC TAC-12.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

117
118                                    Figure 1 - ENUM Functional Architecture
119

120   SECTION 5.0              OPERATIONAL & INFRASTRUCTURE REQUIREMENTS
121   Ed. numbering in this section needed fixed]
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.
124

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


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 Registry
131   database, and it should provide estimates of demand if necessary. (See SLR Section)
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 users,
137             workload volume, or database size increases.
138            Shall maintain a high level of availability as required by SLR’s contained herein. An 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 local
156             data stores
157            Support open standard interface(s)
158
159   5.3    Thick Registry Model
160   [ed Penn Pfautz will re-write Section 5.3)
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 a
166   source for all ContactInfo queries.
167                    Escrow – transfers – lawful access
168                    Contact Info Single Source for all quires

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


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

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


215   5.5.1   Introduction
216   This section describes specific requirements for the Tier 1B operator to maintain a „ContactInfo‟ database.
217   Also included in this section are the following: how the database should be operated, and what
218   information should be publicly accessible.
219   5.5.2   Need for ContactInfo Databases
220      1. There is a need for the Tier 1B Operator to maintain ContactInfo databases associated with ENUM
221         registrations.
222      2. The appropriate technology for maintaining public access to such ContactInfo should be the IRIS
223         protocol developed by the CRISP Working Group.
224      3. There is a requirement on the TIER 1B operator to maintain such a database in a manner known
225         as the “Thick Registry” where the TIER 1B Registry operator maintains the authoritative database
226         of registration information obtained from all Registrars.
227      4. The information from that database that could be made publicly accessible is a matter of policy
228         for the CC1 ENUM LLC to determine, to ensure compliance with privacy regulations and best
229         practices.
230
231
232   5.5.4   General ContactInfo Requirements
233   The general requirements for the ContactInfo database are:
234      1. Mining Prevention: providing some technical means to discourage data mining of the information
235         base
236      2. Standard and Extensible Schemas
237      3. Level of access: not all data need be equally accessible by all users of the service
238      4. Client processing: facilitating the creation of client software that can automatically extract
239         relevant details from the services responses
240      5. Optional Decentralization: the protocol must not require that all data be aggregated in some
241         central repository in order to provide service
242      6. Authentication Distribution: Editor’s note – this item is unclear - more clarification is necessary the
243         protocol itself must not require individual service operators to participate in a single standard
244         authentication system
245      7. Lookups: the protocol must allow a nameserver lookup given a fully qualified host name or IP
246         address of a name server
247      8. Searches: The protocol should provide for flexible access by authorized entities while limiting
248         public queries to searches by full telephone number only.
249      9. Result Set Limits: the protocol must include provisions for allowing a server operator to express a
250         client search limit
251   ContactInfo Databases must be policy neutral
252           a.   Access can be anonymous and or authenticated
253           b.   Data can be given to some users and/or not to others
254           c.   Trust can be based locally regionally, globally or all of the above
255           d.   Information can be centralized distributed or centrally indexed but distributed or all of the
256                above
257
258   Contact-Info Databases should use modern Authentication and Authorizations methods
                                                          11
      Tier 1B Technical and Operational Requirements                     CC1 ENUM LLC TAC-12.00001-2005


259           a. Authentication: passwords, one time passwords, digital certificates, references
260           b. Authorization: user based, sequence based, chain based, attribute based, time based, refer based.
261
262   5.5.5   Data Collection Requirements and ContactInfo Data Access
263   The Tier 1B operator will ultimately accredit various entities to perform the function of ENUM
264   Registrars. Those Registrars will as part of the registration process collect a variety of data associated
265   with ENUM registrations which may include the registrant, billing contacts, technical contacts,
266   administrative contacts, legal contacts, zone contacts, abuse contacts, and security contacts. The data that
267   can be collected will ultimately be determined by the ENUM LLC as a matter of policy.
268
269   ENUM accredited Registrars will ultimately transmit copies of specified data for each registration to the
270   Tier 1B operator for maintenance under the concept of a “thick Registry”.
271
272   The Tier 1B operator will then take portions of the data; such as Registrar contact data and populate an
273   IRIS database with that information for public access. What data is to be publicly accessible is a matter of
274   policy to be determined by the CC1 ENUM LLC.
275
276   Below, are the recommended data elements that should be included in the Zone ContactInfo. This
277   information is pertinent to the Tier 2 that stores the actual NAPTR records. The data elements that are
278   marked as public must be made available to all queries. All data in the database must be true and
279   accurate. The use of proxied data is not allowed.
280
281   Table 2 - 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


                                                           12
      Tier 1B Technical and Operational Requirements                      CC1 ENUM LLC TAC-12.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

282
283    Below are the recommended data elements that should be included in the Registrar ContactInfo. The
284   data elements that are marked as public must be made available to all queries All data in the database
285   must be true and accurate. The use of proxied data is not allowed. The data elements that are marked as
286   private must be secured in the ContactInfo database and only available to queries that have the
287   appropriate authorization. The registrant has the right to change the default data elements that are
288   marked as private to public at their discretion. If a data element is marked optional, then there is no
289   requirement for populating those fields. These fields should be populated with role-based information
290   (e.g. email address abuse@xyz.com)
291
292   Table 3 - 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

                                                           13
      Tier 1B Technical and Operational Requirements        CC1 ENUM LLC TAC-12.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

293
294   * * *REVIEW STOPPED HERE 9/23/05 * * *
295


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


296   5.4.6   Privacy Considerations
297   ENUM Registrars and registries will comply with applicable regulations on the collection of personally
298   identifying information and disclose the reasons for the collection and publication of such data.
299
300   Even though the ENUM Registry will maintain a full and complete copy of all relevant data associated
301   with ENUM registrations in accordance with the requirement for a “thick Registry”, it is anticipated that
302   Registrars will handle normal and routine inquiries about registrants. The Registry operator will refer
303   such inquires to the appropriate Registrar.
304
305   It is anticipated that personally identifying registrant information associated with ENUM would not be
306   made publicly available through the ENUM ContactInfo system, however such data could be made
307   available to authorized entities (such as Law Enforcement agencies) under appropriate authentication
308   and authorization procedures.
309
310   Many individuals, businesses or institutions may, however, may choose to have personally identifying
311   information exposed in the ContactInfo system. The Registry-Registrar interface SHOULD be able to flag
312   appropriate fields for the Registry to publish in a separate registrant info field.
313
314   In certain special cases where the registrant chooses to manage its own DNS infrastructure the registrant
315   may also be the zone contact. Under these circumstances the requirement for publishing zone contact
316   data may override personal privacy considerations. In those cases the registrant will be fully informed
317   via an appropriate disclosure of the circumstances and necessity to publish such data.
318
319   5.4.7   Recommendation
320   It is recommended that, Registrar contact, zone contact and zone administration contact data always be
321   made publicly available and, optionally registrant information data at the explicit request of the
322   registrant.
323
324   5.4.8   Escrow Requirement
325   An escrow agreement for all Registry-Registrar data contained within the ContactInfo database between
326   the Tier 1B Registry operator, an appropriate escrow service provider, and the CC1 ENUMLLC will be is
327   essential to ensure business continuity and stability of the 1.e164.arpa service.
328
329   5.5     Security (Section replaced with revised text)
330   A Tier 1B must secure both Registry operations and data. A Registry shall conduct comprehensive threat
331   analyses on all parts of the Registry system to identify the vulnerable points and the types of security
332   attacks. Based on the analyses, the Registry shall define and implement multi-tiered procedures that
333   provide security protections to all parts of the Registry system
334   5.5.1   Operational System Security
335          Protection/Prevention of compromise of the systems hosting or managing Tier 1B

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


336          Protection from Denial of Service attacks (internal & external)
337          Requirements for maintaining security updates for all software
338          Security (integrity, authenticity) of communications between the components of the Tier 1A and
339           1B service (name servers, registry, etc)
340          Encryption requirements
341          Authentication & Authorization requirements
342          Requirements on ISPs providing connectivity for Tier 1B
343   5.5.2   Physical Security
344          The Tier 1B Registry shall employ a variety of physical security systems to ensure that
345           unauthorized personnel have no access to sensitive equipment and/or data.
346          All servers containing any sensitive data shall be physically secured so that only a controlled list
347           of people can obtain access.
348          The hosting centers shall be secured so that no access to the internal networks is possible for
349           unauthorized persons. All internal networks shall be isolated from public access, and external
350           Internet links shall be firewall-protected to prevent intruders from gaining access.
351          Physical precautions inside the server rooms shall include movement detectors (using infra-red or
352           similar means) to alert security personnel should an intruder gain access to a secured location.
353           Alarms will be fitted to all doors and windows, which open into or out of a restricted area.
354          The doors and windows shall be secure enough to withstand a reasonable amount of force, and
355           damage to doors or windows shall also trigger the alarms.
356          Security staff shall be present at all times, and should have sufficient training to enable them to
357           correct most problems. Appropriate personnel shall also be contacted when necessary to help
358           contain the situation.
359          Access to the server room shall be controlled by a two-factor authentication system. An
360           authorized individual shall require both an authorized access token and a valid PIN or passcode
361           to gain physical access to the servers. Any use of an access token shall be logged and such logs
362           shall be archived for at least 1 year.
363           Should an access card be lost or stolen, it is the responsibility of each employee to report this in a
364           timely manner so that the lost card may be deactivated and a new card issued. Closed circuit TV
365           shall be in place at all sites for identification purposes should an unauthorized person attempt to
366           use a stolen access card. Personnel authorized temporary access to the servers, but not
367           permanently issued access tokens, shall be escorted by permanent staff while within the restricted
368           space.
369          24-hour access to the data center by authorized personnel shall not be hindered by aforesaid
370           security measures.
371   5.5.3   Network Security
372          User identification, passwords, and IP range checking shall be required for all restricted services
373           (which includes services other than DNS resolution.).
374          Secure File Transfer Protocols shall be used for all "file transfers" between the ENUM Tier 1Bs and
375           the Tier 1A Registry [RFC 2228, RFC 2577, or similar equivalent].

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


376          System maintenance shall be performed via SSL or similarly secured connections. Telnet servers
377           shall not be operational on any system on the DNS network due to their security risk.
378          Each system shall operate a very restricted set of basic services in the relevant sections for DNS,
379           ContactInfo, FTP, SCP, and WWW services. Systems shall be firewall-protected in hardware, and
380           IP filtering rule sets shall be in place to reject packets that are not appropriate for a particular host.
381          DNS servers shall run a minimum set of applications and system services, in addition to the DNS
382           server software.
383          Checks shall take place on all DNS servers to ensure that data integrity is maintained.
384          Services which are IP-restricted shall have each IP address specified individually. Network
385           addresses are not to be used, since this adds the risk that a host could masquerade as a spare IP
386           address on an internal network.
387          Packet "sniffers", designed to check all traffic passing through a network interface, shall be in
388           place to catch suspicious traffic. These will actively scan for incorrect or illegal packets, and alert
389           the security team. Packet sniffers may also give some indication of the source of an attack, which
390           would be of use in preventing that attack in the future.
391          Network security shall be verified by a security audit process, which involves scanning from an
392           internet-connected host all TCP and UDP ports on servers operated by the Tier 1B Registry.
393          Security tests shall be performed on the DNS Servers and a corresponding report audited on a
394           regular basis. Each test will attempt to take advantage of a security flaw using a specific attack
395           method, and the result shall be reported. Here is an non-exhaustive list of known attacks:
396              o Buffer overflow exploit
397              o Missing format string exploit
398              o Packet fragmentation attack
399              o Data flooding (SMURF ping, etc.)
400              o DNS spoofing
401              o FTP spoofing
402              o Dictionary passwords
403              o Replay attack
404              o Denial of service (DoS)
405   Some of these attacks may not be applicable to all services.
406   The Tier 1B Registry shall update the tests used when new vulnerabilities, security flaws, or techniques
407   are discovered. The updates shall be based on information from security-related mailing lists, websites,
408   newsgroups, and industry best practices.
409   5.5.4   Backup Security
410          Backup shall be performed through a secure network on the main Tier 1B Registry site.
411          The Tier 1B Registry shall use an encryption scheme for the backup of sensitive data as a part of
412           the implementation process.
413          Backup information shall be stored in a secure off-site location.
414   5.5.5   Security Audit and Reporting
415   The Tier 1B Registry shall run a security audit on a regular basis but no less often than once per quarter.



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


416            The Tier 1B Registry shall run a security audit to test all systems for configuration issues and
417             security vulnerabilities. Results of this audit should then form the basis of a quarterly security
418             audit report, which will also detail any recommendations for system alterations and a timeline for
419             remediation.
420            All security breaches are to be reported to the Registry management responsible for security and
421             to the CC1 ENUM LLC. Should a serious breach be detected, some services may be suspended
422             temporarily if this is necessary to ensure the reliability of the Tier 1B Registry data. Bidders
423             should detail the hierarchy of breach severity and escalation procedures.
424   The Tier 1B Registry shall provide a monthly security status report to the CC1 ENUM LLC,
425   including a list of security incidents categorized by severity.
426   5.5.6 Backup Security
427            Backup shall be performed through a secure network on the main Tier 1B Registry site.
428            The Tier 1B Registry shall use an encryption scheme for the backup of sensitive data as a part of the
429             implementation process.
430            Backup information shall be stored in a secure off-site location.
431
432   5.5.7     Security Audit and Reporting
433   The Tier 1B Registry shall run a security audit on a regular basis but no less often than once per quarter.
434            The Tier 1B Registry shall run a security audit to test all systems for configuration issues and security
435             vulnerabilities. Results of this audit should then form the basis of a quarterly security auditreport, which
436             will also detail any recommendations for system alterations and a timeline for remediation.
437            All security breaches are to be reported to the Registry management responsible for security and to the
438             LLC. Should a serious breach be detected, some services may be suspended temporarily if this is necessary
439             to ensure the reliability of the Tier 1B Registry data. [Note to LLC: bidders should detail hierarchy of
440             breach severity and escalation procedures.]
441            The Tier 1B Registry shall provide a monthly security status report to the CC1 ENUM LLC, including a list
442             of security incidents categorized by severity.
443
444   5.6       Customer Service Personnel
445   . Tier 1B is required to protect their personnel’s access from all forms of abuse, fraud or security breaches. In
446   addition, the Tier 1B must follow any and all commercial practices used to protect credit card information (Gramm-
447   Leach-Bliley Act).
448
449   5.7       Caching Requirements
450   This section refers to the minimum requirements for caching. Bidders need to respond with recommended name
451   server caching requirements for time to live (TTL).
452
453   5.8       System Turn-Up and Testing
454   Bidders need to provide a detailed start-up project implementation and system test plan, including proposed test
455   cases, to support the Tier 1B registry system turn-up. Bidders are required to provide high level start-up project
456   implementation timelines and plans as part of their bid proposal.

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


457
458   5.9       Beta ?? Period
459   Editor’s note – need to add details regarding the steps and requirements for the Operational Beta period
460
461   5.10      Operations and Maintenance
462   ENUM is envisioned as a wholly robust and high-availability service. An ENUM Tier 1B Registry candidate
463   should describe how it would operate and maintain the various aspects of the Registry at a high service level. It
464   should include descriptions of how it intends to ensure system outage prevention, system recovery procedures, and
465   technical support. Bidders should also include descriptions of how they intend to ensure system outage
466   prevention, system recovery procedures, and technical support, including arrangements for power,
467   HVAC (Heating, Ventilating, and Air Conditioning), and fire systems.
468
469   An ENUM Tier 1B Registry candidate should also describe how it intends on meeting the following operations and
470   maintenance requirements.
471   A Registry shall:
472            Use redundancy and high-availability system architectures to eliminate planned or unplanned downtime of
473             the whole system. That is, Registry service shall remain operational when part of the system is undergoing
474             software or hardware upgrades and system backups.
475            Use redundancy and high-availability system architectures to minimize unplanned downtime.
476            Employ a comprehensive set of system monitoring procedures for problem detection and resolution at
477             multiple levels of the architecture, including processor, memory, operating system, database, application
478             process, and network connectivity.
479            Make available backup software, operating systems and hardware in all data centers.
480            Employ a streamlined technical support process to ensure that the appropriate staffs resolve all
481             problems in a timely manner
482
483   5.11      System Outage Prevention and Recovery
484   An ENUM Tier 1B Registry requires outage prevention measures specifically designed to minimize system
485   component downtime. Downtime relates to individual components in a redundant system and can be either planned
486   or unplanned., Unplanned downtime is caused by failures in external communications, power, or internal network or
487   computer equipment; or planned, which occurs when a system is unavailable due to scheduled maintenance (e.g.,
488   during software or hardware upgrades and system backups).
489
490   5.11.1 System Recovery Procedures
491   System recovery refers to the process of bringing the system back to normal operations after the system has gone
492   down due to failures. The goal is to minimize downtime, data loss and adverse impacts on other systems.
493   An ENUM Tier 1B Registry candidate should describe how it intends on meeting the following operations and
494   maintenance requirements.
495   A Registry shall:
496            Employ recovery procedures for failures that occur at different parts of the Registry system, such as:
497                - Data center failures
498                - Database failures
499                - Server failures
                                                                 19
      Tier 1B Technical and Operational Requirements                          CC1 ENUM LLC TAC-12.00001-2005


500                - Network failures
501          Specify how redundancy and highly-available Registry architecture will help expedite recovery from these
502           failures.
503          Specify how backup and escrow data will be used for recovery from these failures.
504
505   In addition, a Registry should:
506          Provide a time estimate for recovering from each type of failure.
507          Log each system outage and document system problems that could result in outages.
508
509   5.11.2 Database Escrow and Backup
510   The goal of any data backup/recovery procedure is full recovery from failures without any loss of data. Data backup
511   strategies handle system hardware failures (e.g., loss of a processor or one or more disk drives) by reinstalling the
512   data from daily backups, supplemented by the information on the “before” and “after” backup files that the database
513   creates. In order to guard against loss of the entire facility because of fire, flood, or other natural or man-made
514   disaster, off-site escrow of the Registry data should be provided in a secured storage facility.
515   An ENUM Tier 1B Registry candidate shall specify:
516              The frequency and procedures for data backup
517              The frequency and procedures for data escrow
518              The hardware and software systems used for data backup
519              The procedures for retrieval of data and rebuild of the database
520              Who should have access to the escrowed data and in what circumstances it would be accessed by an
521               entity other than itself
522              Testing process and schedule to verify the escrow and database backup procedure
523              The data escrow arrangements, including any contractual arrangements with Third parties
524
525   In addition, the following safeguards are required of ENUM Tier 1B Registry candidates:
526          The data backup and escrow procedures shall not impede the overall performance of normal Registry
527           operations
528          The data backup and recovery procedures shall minimize the data loss and service interruption of the
529           Registry
530
531   5.12 Technical and Other Support
532   The Tier 1B Registry must act as technical liaison with Tier 1A for resolution of issues with respect to the
533   delegation of authority over a country’s NPA’s within 1.e164.arpa.
534   The Tier 1B Registry must provide technical and other support to Registrars and Tier 2 service providers
535   from an appropriate customer help desk with a well-defined escalation policy.
536
537          A Registry may provide web-based support to Registrars, Tier 2 service providers, and Internet
538           users at large. The web contents may include knowledge bases, FAQ‟s, toolkits, white papers, and
539           email messaging.
540




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


541   5.13 Other Responsibilities of the Tier 1B Registry
542   The Tier 1B Registry will use commercially reasonable efforts to restore the critical components of the
543   system within 48 hours in the case of a force majeure event. No single event should result in an outage of
544   DNS resolution service itself.
545   Except in the case of nameserver performance requirements, the Tier 1B Registry will perform internal
546   monitoring as a means to verify that the availability and performance measurements of this document are
547   being met.
548   Beginning no later than 120 days after the commencement-of-service date, the Tier 1A Registry will
549   provide preliminary monthly system performance and availability reports to the contracting entity.
550   The Tier 1B Registry will provide service availability percentages during each Performance Measurement
551   Period as listed in this document.
552
553   5.14   Transition
554   (Editor‟s Note: Need to add text regarding operations, and system transition to new vendor)
555   The Tier 1B Registry must provide a plan for transitioning of the Registry to a new provider should that
556   be required under the terms of the contract. The plan must ensure no disruption of ENUM DNS service.
557
558   5.15   Accommodation of Future Internet Architectural Enhancements
559   Bidders must respond with plan to accommodate IPv6 per RFC 2874.

560   SECTION 6.0            SERVICE LEVEL REQUIREMENTS (SLR)
561   Editor’s Note – Additional details to be provided by Richard, Tim and Kevin
562   Editor’s Note: Section needs to be synchronized with Tier 1A along with adding additional SRS requirements.
563   This section provides requirements for timeliness and reliability of the ENUM Tier 1B Registry. It also provides
564   metrics for measuring reliability.
565
566   (Editor’s Note: New Definitions proposed need to review Section 3 for additions
567
568   6.1    Performance Specifications
569   Registry operator shall use commercially reasonable efforts to provide Registry Services for the Registry
570   TLD. The Performance Specifications defined below establish the basis for the Service Level Exception
571   Credits ("SLE Credits") provided for in a Registry Agreement. These Performance Specifications also set
572   forth Registry Operator's obligations directly to the Tier 1B under the Registry Agreement.
573
574   6.2     Service Availability
575   Service Availability is defined as the time, in minutes, that the Registry's Core Services are responding to
576   its users. Service is unavailable when a service listed in the Matrix is unavailable to all users, that is, when
577   no user can initiate a session with or receive a response from the Registry ("Unavailability"). Service
578   Availability is a C1 priority level.
579
580   Service Availability is measured as follows:
                                                             21
      Tier 1B Technical and Operational Requirements                      CC1 ENUM LLC TAC-12.00001-2005


581   -   Service Availability % = {[(TM - POM) - UOM] / (TM - POM)}*100 where: TM = Total Minutes in
582       the Service Level Measurement Period (#days*24 hours*60 minutes)
583   -   POM = Planned Outage Minutes (sum of (i) Planned Outages and (ii) Extended Planned Outages
584       during the Service Level Measurement Period)
585   -   UOM = Unplanned Outage Minutes (Difference between the total number of minutes of Unavailability
586       during the Service Level Measurement Period minus POM.
587
588   Upon written request, and at the sole expense of the requesting Registrar(s), Registry Operator will retain
589   an independent third party (to be selected by Registry Operator with the consent of the Registrar(s) to
590   perform an independent calculation of the UOM). The frequency of this audit will be no more than once
591   yearly during the term of the agreement between Registry Operator and the Registrar. This calculation is
592   performed and the results reported for each calendar month for SRS and WHOIS availability and for each
593   calendar year for Nameserver availability.
594
595   6.3    Service Availability - SRS
596   Service Availability as it applies to the SRS refers to the ability of the SRS to respond to Registrars that
597   access and use the SRS through the EPP or designated protocol.. SRS Unavailability will be logged with
598   the Registry Operator as Unplanned Outage Minutes. The committed Service Availability for SRS is
599   99.95% and the Service Level Measurement Period is monthly.
600
601   1. Service Availability Nameserver Service
602   Service Availability as it applies to the Nameserver refers to the ability of the Nameserver to resolve a
603   DNS query from an Internet user. Nameserver Unavailability will be logged with the Registry Operator as
604   Unplanned Outage Minutes. The committed Service Availability for Nameserver is 100% and the Service
605   Level Measurement Period is annually.
606
607   2. Total Nameserver Availability
608   In addition, no less than 80% of nameserver sites will be available at any given time. For purposes of this
609   SLA, "nameserver site" shall mean distinct locations that host a .NET nameserver(s). For example
610   Sterling, VA, USA and Tokyo, Japan are 2 nameserver sites.
611
612   3. Service Availability
613   WHOIS = 100%. Service Availability as it applies to WHOIS refers to the ability of users to access and
614   use the Registry's WHOIS service. WHOIS Unavailability will be logged with the Registry Operator as
615   Unplanned Outage Minutes. The committed Service Availability for WHOIS is 100% and the Service
616   Level Measurement Period is monthly.
617
618   6.4     Planned Outage
619   High volume data centers like the Registry require downtime for regular maintenance. Allowing for
620   regular maintenance ("Planned Outage") ensures a high level of service for the Registry. Planned Outage
621   Performance Specifications are a C4 priority level.
622
623   1. Planned Outage Duration
624   The Planned Outage Duration defines the maximum allowable time, in hours and minutes that the
625   Registry Operator is allowed to take the Registry Services out of service for regular maintenance. Planned
626   Outages are planned in advance and the Registrar community is provided warning ahead of time (Editor’s

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


627   Note: What is the minimum notification period). This Performance Specification, where applicable, has a
628   monthly Service Level Measurement Period. The Planned Outage Duration for the Core Services is as
629   follows:
630   - Planned Outage Duration -- SRS = 8 hours (480 minutes) per month, can be split between 2 days;
631   - Planned Outage Duration -- Nameserver = (no planned outages allowed); and
632   - Planned Outage Duration - WHOIS = (no planned outage allowed).
633
634   2. Planned Outage Timeframe
635   The Planned Outage Timeframe defines the hours and days in which the Planned Outage can occur. The
636   Planned Outage Timeframe for the Core Services is as follows:
637   - Planned Outage Timeframe -- SRS = 0500-1300 UTC Sunday;
638   - Planned Outage Timeframe -- Nameserver = (no planned outages allowed); and
639   - Planned Outage Timeframe - WHOIS (no planned outages allowed).
640
641   3. Planned Outage Notification
642   The Registry Operator must notify all of its Registrars of any Planned Outage. The Planned Outage
643   Notification Performance Specification defines the number of days prior to a Planned Outage that the
644   Registry Operator must notify its Registrars. The Planned Outage Notification for the Core Services is as
645   follows:
646   - Planned Outage Notification Timeframe -- SRS = 7 days;
647   - Planned Outage Notification Timeframe -- Nameserver = (no planned outages allowed); and
648   - Planned Outage Notification Timeframe - WHOIS (no planned outages allowed).
649
650   6.5     Extended Planned Outage
651   In some cases such as software upgrades and platform replacements an extended maintenance timeframe
652   is required. Extended Planned Outages refers to additional hours that can be added to a monthly planned
653   outage. Extended Planned Outages will occur less frequently than Planned Outages. Extended Planned
654   Outage Performance Specifications are a C4 priority level.
655
656   1. Extended Planned Outage Duration
657   The Extended Planned Outage Duration defines the maximum allowable time, in hours and minutes, that
658   the Registry Operator is allowed to take the Registry Services out of service for extended maintenance.
659   Extended Planned Outages are planned in advance and the Registrar community is provided warning
660   ahead of time. Extended Planned Outage periods are in addition to any Planned Outages during any
661   Service Level Measurement Period. This Performance Specification, where applicable, has a Service
662   Level Measurement Period based on a calendar year. The Extended Planned Outage
663   Duration for the Core Services is as follows:
664   - Extended Planned Outage Duration - SRS = 8 hours (480 minutes) per calendar year;
665   - Extended Planned Outage Duration - Nameserver = (no planned outages allowed); and
666   - Extended Planned Outage Duration - WHOIS (no planned outages allowed).
667
668   2. Extended Planned Outage Timeframe
669   The Extended Planned Outage Timeframe defines the hours and days in which the Extended Planned
670   Outage can occur. The Extended Planned Outage Timeframe for the Core Services is as follows:
671   - Extended Planned Outage Timeframe - SRS = 0100 - 1700 UTC Saturday or Sunday;
672   - Extended Planned Outage Timeframe - Nameserver = (no planned outages allowed); and

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


673   -     Extended Planned Outage Timeframe - WHOIS (no planned outages allowed).
674
675   3. Extended Planned Outage Notification
676   The Registry Operator must notify all of its Registrars of any Extended Planned Outage. The Extended
677   Planned Outage Notification Performance Specification defines the number of days prior to an Extended
678   Planned Outage that the Registry Operator must notify its Registrars. The Extended Planned Outage
679   Notification for the Core Services is as follows:
680   - Extended Planned Outage Notification - SRS = 28 days;
681   - Extended Planned Outage Notification - Nameserver =(no planned outages allowed); and
682   - Extended Planned Outage Notification - WHOIS (no planned outages allowed).
683
684   6.6      Processing Time
685   Processing Time is an important measurement of transaction-based services like the Registry. Processing
686   Time measures the quality of that service.
687
688   Processing Time refers to the time that the Registry Operator receives a request and sends a response to
689   that request. Since each of the Registry Services has a unique function, the Performance Specifications for
690   Processing Time are unique to each of the Registry Services. For example, a Performance Specification for
691   the Nameserver is not applicable to the SRS and WHOIS, etc.
692
693   Processing Time Performance Specifications are a C2 priority level. Processing Time Performance
694   Specifications have a monthly Service Level Measurement Period and will be reported on a monthly
695   basis. The Registry Operator will log the processing time for all of the related transactions, measured
696   from the time it receives the request to the time that it returns a response.
697
698   1. Processing Time Add, Modify, Delete = 1000 milliseconds for 95%.
699   - Processing Time - Add, Modify, and Delete is applicable to the SRS as accessed through the EPP
700      protocol defined in Appendix C. It measures the processing time for add, modify, and delete
701      transactions associated with domain names, nameservers, contacts, and Registrar profile information.
702   - The Performance Specification is 1000 milliseconds for 95% of the transactions processed. That is,
703      95% of the transactions will take 1000 millisecond or less from the time the Registry Operator
704      receives the request to the time it provides a response.
705
706   2. Processing Time--Query Domain
707   - Processing Time - Query Domain is applicable to the SRS as accessed through the designated
708      protocol. It measures the processing time for an availability query of a specific domain name.
709   - The performance specification is 500 milliseconds for 95% of the transactions. That is, 95% of the
710      transactions will take 500 milliseconds or less from the time the Registry Operator receives the query
711      to the time it provides a response as to the domain name's availability.
712
713   3. Processing Time--WHOIS Query
714   - Processing Time - WHOIS Query is only applicable to the WHOIS. It measures the processing time
715      for a WHOIS Query.


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


716   -   The Performance Specification is 1000 milliseconds for 95% of the transactions. That is, 95% of the
717       transactions will take 1000 milliseconds or less from the time the WHOIS receives a query to the time
718       it responds.
719
720   4. Processing Time--Nameserver Resolution
721   - Processing Time - Nameserver Resolution is only applicable to the Nameserver. It measures the
722      processing time for a DNS query.
723   - The Performance Specification is 250 milliseconds for 95% of the transactions. That is, 95% of the
724      transactions will take 250 milliseconds or less from the time Nameserver receives the DNS query to
725      the time it provides a response.
726
727   5. Update Frequency
728   There are two important elements of the Registry that are updated frequently and are used by the general
729   public; Nameserver and WHOIS. Registrars generate these updates through the SRS. The SRS then
730   updates the Nameserver and the WHOIS. These will be done on a batch basis. Update Frequency
731   Performance Specifications are a C3 priority level.
732
733   The committed Performance Specification with regard to Update Frequency for both the Nameserver and
734   the WHOIS is 10 minutes for 95% of the transactions. That is, 95% of the updates to the Nameserver and
735   WHOIS will be effectuated within 10 minutes. This is measured from the time that the registry confirms
736   the update to the Registrar to the time the update appears in the Nameserver and WHOIS. Update
737   Frequency Performance Specifications have a monthly Service Level Measurement Period and will be
738   reported on a monthly basis.
739   - Update Frequency--Nameserver = 10 minutes for 95%.
740   - Update Frequency--WHOIS = 10 minutes for 95%.
741
742   6.7     Cross-Network Nameserver Performance Requirements
743   Nameserver round-trip-time and packet loss from the Internet are important elements of the quality of
744   service provided by the Registry Operator. These characteristics, however, are affected by Internet
745   performance and therefore cannot be closely controlled by Registry Operator. Accordingly, these
746   requirements are not matters subject to Service Level Exceptions and credits under the Service Level
747   Agreement, but they are Registry Operator obligations in the Registry Agreement.
748
749   The committed Performance Specification for cross-network nameserver performance is a measured
750   round-trip time (RTT) of under 300 ms and measured packet loss of under 10%. Cross-network
751   nameserver performance measurements will be conducted by ICANN at times of its choosing, in the
752   following manner:
753
754   The measurements will be conducted by sending strings of DNS request packets from each of four
755   measuring locations to each of the .NET nameservers and observing the responses from the .NET
756   nameservers. (These strings of requests and responses are referred to as a "CNNP Test".) The measuring
757   locations will be 4 locations within the NANP. (Editor’s Note – locations within the country and or
758   NANP need to be specified)
759   - Each string of request packets will consist of 100 UDP packets at 10 second intervals requesting ns
760       records for arbitrarily selected .NET second-level domains, preselected to ensure that the names exist
761       in the Registry TLD and are resolvable. The packet loss (i.e. the percentage of response packets not
762       received) and the average round-trip time for response packets received will be noted.
                                                          25
      Tier 1B Technical and Operational Requirements                       CC1 ENUM LLC TAC-12.00001-2005


763   -   To meet the packet loss and round-trip-time requirements for a particular CNNP Test, all measured
764       RTTs must be less than 300 ms and these must be less than 10% packet loss.
765   -   Any failing CNNP Test result obtained during an identified Core Internet Service Failure shall not be
766       considered.
767   -   To ensure a properly diverse testing sample, Registry Operator will contract with a third party to
768       perform the test and provide the results to ICANN and the Registry Operator. The CNNP Tests at
769       varying times (i.e. at different times of the day, as well as on different days of the week). Registry
770       operator will be deemed to have failed to meet the cross-network nameserver performance requirement
771       only if the .NET nameservers persistently fail the CNNP Tests with no less than three consecutive
772       failed CNNP Tests to be considered to have persistently failed.
773   -   In the event of persistent failure of the CNNP Tests, the Tier 1B will give the Registry Operator
774       written notice of the failures (with backup data) and Registry Operator will have sixty days to cure the
775       failure. Notice will also be sent to the CC1 ENUM LLC.
776   -   If, following that opportunity to cure, the .NET nameservers continue to persistently fail CNNP Tests
777       and Registry Operator fails to resolve the problem after thirty days notice of the continuing failures,
778       Registry Operator will be deemed not to have met its obligations under the Registry Agreement.
779   -   Sixty days prior to the commencement of testing under this provision, the Tier 1B will provide the
780       Tier 1A,Registrar’s and Tier 2 Registry Operator Editor’s Note – need to clarify who is being referred
781       to as registry operator with the opportunity to evaluate the testing tools and procedures to be used by
782       the Tier 1B. In the event that Registry Operator does not approve of such tools and procedures, the
783       Tier 1B will work directly with Registry Operator to make necessary modifications.
784
785   6.8    Responsibilities of the Parties
786   Except in the case of nameserver performance measurements, the Registry Operator will perform
787   monitoring from internally located systems as a means to verify that the availability and performance
788   measurements in this document are being met.
789
790   -   Beginning no later than 90 days post Commencement-of-Service Date, the Registry Operator will
791       publish preliminary weekly system performance and availability reports. Registry operator will use
792       best efforts to finalize these reports no later than 30 days after the preliminary reports are provided.
793   -   The Registry Operator will use commercially reasonable efforts to restore the critical systems of the
794       Core Services within 24 hours after the termination of a force majeure event and restore full system
795       functionality within 48 hours after the termination of a force majeure event. Outages due to a force
796       majeure will not be considered Service Unavailability.
797
798   Verisign Registry Reporting Contribution
799
800   Tier 1B Registry reporting to Registrar and LLC
801
802   Purpose:
803   The registry should make available regular reports for the registrars on the daily, weekly, and monthly
804   activity. The monthly level report should provide the necessary details for end of month billing. Further
805   more a monthly report on performance and major activities should be reported to the LLC.
806

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


807   Tier 1B Registry Reporting for Registrars:
808   Registrars require easy-to-use tools and reports to assist them in managing their business. The registry
809   should provide daily, weekly, and monthly reports that are available to registrars via a secured file
810   transfer protocol (FTP) server. To assist registrars in their ability to monitor their registration activity
811   throughout the month, the Tier 1B registry should generate daily and weekly reports for each of our
812   registrars, as listed in Table 1 listed below.
813
814   Registrars are able to use these reports to monitor their registration activities and to reconcile their
815   activity to the monthly billing reports. These reports are published on the first day of each month and
816   provide registrars with a means to reconcile their monthly invoices to their transaction activities, listed
817   below:
818
819   * Registrations (including deletions within the grace period)
820   * Transfers (including deletions within the grace period)
821   * Auto-renewals (including deletions within the grace period)
822   * Explicit Renewals (including deletions within the grace period)
823   * Restores
824   * Syncs
825   * Non-Refund Deletions
826
827   The monthly reports include the transactions for the previous month as well as the grace period deletes
828   for the previous month. The grace period deletions are flagged with a deletion date. The domains that are
829   deleted outside the grace period will continue to be listed on separate reports. These "non-refund"
830   reports include all deletions from the previous month that occurred outside the grace period, whether or
831   not they were added, renewed, auto-renewed, or transferred during that month or during a prior month.
832
833   The reports reflect the actual activity for the period that affected the registrar deposit account. The
834   registrars receive one monthly invoice reflecting the counts for all billable activity for the month and the
835   detail behind the summary counts on the invoice are provided in the detail reports identified above. The
836   system associates a transaction ID with every transaction that occurs in the system. These transaction IDs
837   provide an audit trail of all financial transactions allowing registrars, as well as the Tier 1B personnel, to
838   easily trace activity during the audit process.
839
840   Table 1. Registrar Reports provided by Tier 1B.

      Report Name                   Report Features

      Daily       Transactional     Lists all RRP transactions that occurred on
      Registrar Report              previous day

      Daily Gaining and Losing      Lists domains transferred in, transferred

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


      Transfer Report              out, or in pending transfer status

      Daily       AutoRenewal      Lists all domain names auto-renewed
      Report                       previous day;
                                   provides domain name and expiration date

      Daily Restore Report         Lists all domain names restored by registrar
                                   previous day. Domains on this report must
                                   have Restore Report submitted through
                                   registrar tool within 7 days.

      Daily SYNC Report            Lists all domains that were synched
                                   previous day

      Daily Pending       Delete   Lists all domain names in PendingDelete
      Report                       status;
                                   Published to all registrars so they can see
                                   what names are up for deletion;
                                   Lists the domain name and the date it is due
                                   for deletion.

      Weekly   Domain     Name     Cumulative report of all domain names
      Report                       managed by registrar;
                                   Lists domain name, create date, expiration
                                   date, and status.

      Weekly    Name      Server   List all name servers managed by your
      Report                       business;
                                   Lists name server name and IP address.

      Weekly Domains Hosted        Lists all domains hosted by your name
      by Name Server Report        servers;
                                   Lists name server and domain names.

      Monthly Billing Detailed
      Report

      Weekly Registrar Report

841
842   Tier 1B Registry Reporting to LLC:
843   On a monthly basis the Tier 1B should provide a report to the LLC that provides details to their
844   performance and major activities. In table 2, is a list of recommended data to be reported.
845
846   Table 2 Monthly LLC report provided by Tier 1B


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


      Accredited Registrar Status.

      Service Level Agreement Performance

      TLD Zone File Access Activity

      Completed EPP interface software releases

      Domain Names Under Sponsorship – Per Registrar

      Name Servers Registered – Per Registrar

      Domain Names Registered by Registry Operator

      Contact Info Service Activity

      Total Monthly Contract Info Queries

      Total Monthly Domain Name Transaction Trend by
      Category

      Total Monthly Name Server Transactions by Category

      Total Monthly Name Server Write Transactions by
      Subcategory

      Average Daily Transaction Range

      E.164 Geographical Registrations Distribution

      Deleted Names - Per Registrar

      Restored Names - Per Registrar

      Violations of Registrar Restore Report - Per Registrar

      Other Information
        a)Total    Monthly      Transactions        by     Category
        b)Total Transactions by Month
        c)Registrations Distribution for reporting month


847
848
849
850
851   6.9      Connectivity (with Service Providers)
852   This section describes the requirements for connectivity of the ENUM Tier 1B registry with the Internet. It can
853   include items such as:
854          Multihoming requirements

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


855       Resilient/Redundant access
856       BGP Peering with ISPs
857
858   An ENUM Tier 1B Registry candidate shall propose service-level requirements it would expect to meet with regard
859   to operations of the ENUM Tier 1B Registry. This shall include the following items:
860         Registry database throughput – number of transactions per second
861         Registry database availability
862         Number of ENUM Registrar accounts
863         Number of concurrent ENUM Registrar-ENUM Registry connections
864         Frequency of zone data generation: rates per day, hour, minute
865         Zone data propagation delay: minutes, seconds
866         Number of nameservers required
867         Frequency of ContactInfo database generation: rates per day, hour, minute
868         ContactInfo query response time
869         ContactInfo query throughput – number of queries per second
870         ContactInfo database availability
871
872   6.10   Performance and Capacity
873   Performance requirements for ENUM Tier 1B Registry include:
874         Raw Throughput supported (e.g., queries per second)
875         Valid throughput (e.g., valid queries & responses per second)
876         Invalid throughput (e.g., how many invalid queries/second without affecting valid operation) ???
877         Average/Mean/… Query/Response delay
878         Registration performance requirements (registrations/unit time)
879         Zone data update frequency (e.g., 5 minute update frequency 95% of the time)
880         Cross-Network Nameserver Performance (as defined by ICANN)
881
882   Performance will be important. ENUM Tier 0 and ENUM Tier 1A Registries are likely to hold information that is
883   readily available from caches. However, ENUM Tier 1B Registry will hold phone numbers and caches from
884   ENUM Tier 1B Registry hits will not aggregate. For example, a cache of a NPA will cover queries for all phone
885   numbers in the NPA, but a cache of a single phone number will only cover queries for that phone number. Thus the
886   ENUM Tier 1B registry is likely to get more queries.
887   Another aspect of performance will be the query/response metrics as measured from sites around the world. The
888   ENUM Tier 1B Registry must support queries from locations all over the world with acceptable performance.
889
890   6.11   ENUM Tier 1B Registry Performance Specifications
891   An ENUM Tier 1B Registry shall use commercially reasonable efforts to provide performance at the levels set forth
892   herein. (Editor’s Note: Should the Tier 1B bidder provide a proposed registry agreement that outlines the
893   minimum performance specifications)
894
895   6.11.1 DNS Service
896   Performance Specifications


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


897           •      The performance specification for DNS Queries is 300 milliseconds (ms) maximum round-trip
898                  time.
899   Availability
900           •      A DNS Point of Presence (PoP) is considered to be Available during a Sampling Period if it
901                  responds to DNS Queries within the performance specification for 95% of all Measured
902                  Transactions within that Sampling Period.
903           •      The DNS service is considered to be Available for a Sampling Period if over 99% of the queries
904                  submitted within that sampling period are responded to within the specified round-trip response
905                  time as specified.
906           •      The total unavailability of the SRS systems shall not exceed 5 minutes per calendar year. This
907                  represents 99.999% system availability. There shall be no simultaneous Planned Outage of SRS
908                  service at over half of the System's SRS PoPs.
909           •      The total unavailability of the DNS name service systems shall be 0%. This represents 100% DNS
910                  name service availability. There shall be no simultaneous Planned Outage of DNS service at over
911                  half of the System's DNS name service PoPs.
912           •      Nameservers shall exceed 99.99% availability
913   6.11.2 Planned Outages
914   Planned Outages will not exceed four (4) hours per calendar week beginning at 0000 GMT Monday, nor total more
915   than eight (8) hours per month. Notwithstanding the foregoing, the Tier 1 Registry may incur one (1) additional
916   Planned Outage of up to eight (8) hrs. per month in duration for major systems or software upgrades (Extended
917   Planned Outages). In months in which Extended Planned Outages occur, no other Planned Outages may occur.
918
919   6.11.3 Updates
920   The Update Time for the DNS service shall not exceed 5 minutes for 95% of all updates.
921
922   6.11.4 Cross Network Nameserver Performance Requirements
923   The committed performance specifications for cross-network nameserver performance is a measured round-trip
924   time of less than 300 ms and measured packet loss of less than 10%. The cross-network nameserver performance
925   requirements of this subsection are in addition to the requirements of subsections above. Cross-network nameserver
926   performance (CNNP) measurements will be conducted by a neutral third party, at times of its choosing, in the
927   following manner:
928           •      The measurements will be conducted by sending strings of DNS request packets from each of four
929                  measuring locations, chosen by the neutral third party, to each of the Tier 2 nameservers and
930                  observing the responses from the Tier 2 nameservers. The measuring locations will be four
931                  locations, which are geographically dispersed in the U.S. Time Zone.
932           •      Each string of request packets will consist of 100 DNS Queries at 10 second intervals requesting
933                  nameserver type resource records for arbitrarily selected ENUM Tier 1B Registry domains,
934                  preselected to ensure that the names exist in the Tier 1 Registry and are resolvable. The packet loss
935                  (i.e., the percentage of response packets not received) and the average round-trip time for response
936                  packets received will be noted.
937           •      To meet the packet loss and round-trip time requirements for a particular CNNP Test, all three of
938                  the following must be true:



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


939                   (1) The round-trip time and packet loss from each measurement location to at least one ENUM Tier
940                   1B nameserver must not exceed the required values.
941                   (2) The round-trip time to 75% of the ENUM Tier 1B nameservers from at least one of the
942                   measurement locations must not exceed the required value.
943                   (3) The packet loss to each of the Tier 1B nameservers from at least one of the measurement
944                   locations must not exceed the required value.
945           •       Any failing CNNP Test result obtained during an identified core Internet service failure shall not be
946                   considered.
947           •       To ensure a properly diverse testing sample, a neutral third party will conduct the CNNP Tests at
948                   varying times (i.e., at different times of the day, as well as on different days of the week). An
949                   ENUM Tier 1B Registry will be deemed to have failed to meet the cross-network nameserver
950                   performance requirement only if the Tier 1B nameservers persistently fail the CNNP Tests.
951                   Persistently failed is defined as the failure of three or more consecutive CNNP tests.
952           •       In the event of persistent failure of the CNNP Tests, the neutral third party will give an ENUM Tier
953                   1B Registry written notice of the failures (with test data) and the ENUM Tier 1B Registry will have
954                   sixty days to cure the failure.
955           •       If, following that opportunity to cure, the Tier 1B nameservers continue to persistently fail CNNP
956                   Tests and an ENUM Tier 1B Registry fails to resolve the problem after thirty days notice of the
957                   continuing failures, an ENUM Tier 1B Registry will be deemed not to have met its performance
958                   obligations.
959           •       Sixty days prior to the commencement of testing under this provision, the neutral third party will
960                   provide the ENUM Tier 1B Registry with the opportunity to evaluate the testing tools and
961                   procedures to be used. In the event that the ENUM Tier 1a Registry does not approve of such tools
962                   and procedures, the neutral third party will work directly with the ENUM Tier 1B Registry to make
963                   necessary modifications.
964           •       The neutral third party shall make available all data relating to CNNP Test results of the ENUM
965                   Tier 1B nameservers to the ENUM Tier 1B Registry. Data will be made available in a well-defined
966                   electronic format no later than the tenth day of the month following the month in which
967                   measurements were taken.
968   6.11.5 EPP Performance Specifications
969          •     The performance specification for add, modify and delete commands is 3000 milliseconds. This is
970                measured from the time the command is completely received until it is completely sent. It is
971                important to note that this specification may not be met during periods of extreme volume.
972           •       The performance specification for check commands is 1500 milliseconds. This is measured from
973                   the time the command is completely received until it is completely sent. It is important to note that
974                   this specification may not be met during periods of extreme volume.
975   The total planned outage should correspond with the specifications set forth herein.
976
977   6.11.6 Responsibilities of the Parties
978   The ENUM Tier 1B Registry will use commercially reasonable efforts to restore the critical components of the
979   system within 48 hours in the case of a force majeure event. Outages due to a force majeure event will not be
980   considered System Unavailability. (Editor’s note – check on NPAC requirements for reference information to use as
981   guide for text to include in this section)


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


982    Except in the case of nameserver performance requirements, the ENUM Tier 1B Registry will perform internal
983    monitoring as a means to verify that the availability and performance measurements of this document are being met.
984    Beginning no later than 120 days after the commencement-of-service date, the ENUM Tier 1B Registry will provide
985    preliminary monthly system performance and availability reports to the contracting entity.
986    The ENUM Tier 1B Registry will provide service availability percentages during each Performance Measurement
987    Period as listed in this document.
988
989    6.12    ENUM Tier 1B Registry Management
990    This section provides requirements for the management and monitoring of events in the ENUM Tier 1B Registry
991    system. This includes logging of events, auditing logs and notification of significant events to personnel for
992    remedial action.
993           Reject illegal commands/requests (e.g., missing mandatory data element) from ENUM Registrars
994           Detect dual registrations for the same ENUM domain name and inform the requesting ENUM Registrar so
995            that it can initiate the dispute resolution process. If a Registrar initiations a dispute resolution process the
996            Tier 1B will notify the original Registrar of the dispute. The ENUM Tier 1B Registry must take appropriate
997            action to protect the integrity of the original registration during the dispute resolution process.
998
999    6.12.1 Reports and Files
1000   (Action Item – Richard/Kevin contribution on reports to that need to be provided)
1001   An ENUM Tier 1B Registry shall provide reporting service to ENUM Registrars and the contracting entity In
1002   addition, it may also make available zone data and ContactInfo data to ENUM Registrars and other contracting
1003   entities. [It’s one thing to make available the zone data entries corresponding to a ENUM Registrar’s
1004   registrations, but the whole zone data should not be made available.]
1005   ENUM Tier 1B Registry reports for Registrars may include:
1006          Daily Reconciliation Reports created from account transaction logs
1007          Daily and Monthly ENUM Registrar Cumulative Reports for domain-name registrations
1008          Transaction logs
1009          Complete database export file of all data entities owned
1010          ENUM Tier 1B Registry reports for the Contracting Agency may include: Total ENUM domain-name
1011           strings processed
1012          Total ENUM domain-names "registered"
1013          [What does “unavailable” refer to???] Total ENUM domain-name strings "unavailable"
1014          Total ENUM domain-name strings "invalid"
1015
1016   An ENUM Tier 1B Registry may provide custom reporting service that would allow ENUM Registrars and the
1017   Contracting Agency to specify report criteria and have the report available for download upon completion. Example
1018   reports are:
1019       Number and name of domain-names registered within any period
1020       Domain-names transferred to/away from ENUM Registrar within a specified period
1021       Change of ownership activity, and time/date requests were processed
1022       Re-delegation activity
1023   These reports should be posted to a secure site (i.e., FTP (File Transfer Protocol)) that can be accessed by the
1024   ENUM Registrars by entering username and pass code.
1025   The format for reports should be easily machine-readable by ENUM Registrars (i.e., XML, CSV).
                                                                 33
       Tier 1B Technical and Operational Requirements                        CC1 ENUM LLC TAC-12.00001-2005


1026   Naming convention of reports should identify the ENUM Registrars, the date the report was created and indicate the
1027   subject of the report.
1028   An ENUM Tier 1B Registry should archive copies of all reports created.
1029   An ENUM Tier 1B Registry candidate is required to address what mechanisms it would use to enable the
1030   contracting entity to:
1031            •       Monitor the initial progress of implementation
1032            •       Monitor the ongoing participation in the offering
1033            •       Monitor and provide feedback regarding the ongoing performance of the Tier 1
1034            •       Monitor ongoing system updates and changes
1035            •       Monitor ongoing policy updates and changes
1036            •       Drive system updates and changes
1037            •       Drive policy updates and changes

1038   SECTION 7.0 REGISTRY-REGISTRAR INTERFACE REQUIREMENTS
1039
1040   The Tier 1B Registry must establish an interface which is available for all ENUM Registrars to use. The common
1041   protocol may be EPP, but this should not preclude other protocols being used between the ENUM Registry and
1042   ENUM Registrars. The protocols to be used on the interface between the ENUM Tier 1B Registry and ENUM
1043   Registrars must be agreed between those parties.
1044
1045   7.1      Shared Registration System (SRS)
1046
1047   A Tier 1B Registry is envisioned as a shared registration system (SRS) whereby accredited competing
1048   Registrars may register ENUM domain names for their customers in the CC1 ENUM name space. The
1049   Tier 1B Registry will be required to develop a Registrar Accreditation process and Registry-Registrar
1050   agreement. The Tier 1B Registry will be prohibited from functioning as a Registrar.
1051
1052   A Tier 1B SRS is required to:
1053        Allow an unlimited number of accredited Registrars to register ENUM domain names in the CC1
1054         ENUM name space
1055        Provide equal access to the system for all accredited Registrars to perform registration related
1056         operations such as:
1057             - Register new ENUM domain names, Tier 2 contacts, or host names
1058             - Check status of registered ENUM domain names, Tier 2 contacts, or host names
1059             - Delete registered ENUM domain names, Tier 2 contacts, or host names
1060             - Renew registered ENUM domain names, Tier 2 contacts, or host names
1061             - Update information about registered ENUM domain names, Tier 2 contacts, or host names
1062             - Transfer ENUM domain name registration among competing accredited Registrars
1063        Support the open standard interface between the Registry and accredited Registrars, as defined in the
1064         IETF extensible provisioning protocol (EPP) standard suite (RFC3730 through RFC3735). The Tier
1065         1B Registry will work with the CC1 ENUM industry to develop extensions to EPP for the purposes of
1066         supporting CC1 ENUM.
1067        New bullet – The common Tier 1B registry protocol for registrars shall be EPP but this should not
1068         preclude other protocols from being used between the registry and registrars. Alternative protocols
                                                              34
       Tier 1B Technical and Operational Requirements                          CC1 ENUM LLC TAC-12.00001-2005


1069       must be an open standard and agreed to by both parties. Once an alternative protocol has been
1070       established by the Tier 1B registry other registrars may also use that interface after notification and
1071       agreement of the Tier 1B registry. (Favored Nation Clause)
1072    Support the “thick registry” model whereby Tier 2 contact1 information about ENUM domain name
1073       registrations is stored in the SRS.
1074    Reject illegal commands/requests (e.g., missing mandatory data element) from ENUM Registrars.
1075    Detect dual registrations for the same ENUM domain name and inform the requesting ENUM
1076       Registrar.
1077    Follow proscribed procedures for updating the zone files and information in the local data stores for
1078       handling area code splits.
1079    Security of the SRS applications shall be provided in part via the mandatory use of the TLS [RFC
1080       2246] protocol for transport layer security.
1081    Each EPP session shall be authenticated and encrypted using TLS. The ENUM Registry shall
1082       authenticate every EPP client connection using both an X.509 server certificate, issued by a
1083       commercial Certification Authority identified by the Tier 1 Registry, and its ENUM Registrar
1084       password.
1085   Or replace with the following text. Editor’s note – need to check into security
1086    Security of the SRS application shall be provided via a mandatory authenticated and encrypted
1087       connection. At a minimum, IPSEC will be used to secure the connection.
1088    Each EPP session shall be authenticated and encrypted using IPSEC. The ENUM Registry shall
1089       authenticate every EPP client connection using a valid PKI.
1090
       1
1091    This may be extended to include the contact data of the Registrant, but this would be in the context of an
1092   escrow for the Registrar and not that the Registry would publicly display this data or otherwise make it
1093   available.
1094
1095   [Possibly include Service Level requirements regarding planned outages, EPP performance specifications,
1096   etc.]
1097   Editor’s Note – Check on registry/registrar contents for alignment
1098        Support batch file processing so that the ENUM Registrar can put many commands into one file and deposit
1099           it in a “command” directory on a Tier 1 B Registry server. The Tier 1 B Registry should move the file to an
1100           archive directory, process the commands based on the order as they appear in the file, and put all the
1101           responses to the commands in the same order in a file that is deposited in a “response” directory on the
1102           same server. ENUM Registrars can periodically check and retrieve files in the “response” directory. Once
1103           the file is read, the ENUM Tier 1B Registry can move the file to an archive directory where it can be
1104           preserved as back-up.
1105        Shall support ENUM Registrars’ operations on Registry objects such as create, query, update, delete and
1106           transfer, as specified by the EPP standards suite.
1107
1108   7.2     Interfaces between ENUM Tier 1A Registry and Tier 1B Registry
1109   Because the Tier 1A registry will likely contain less than a thousand records and additions and changes are expected
1110   to be infrequent, a formal mechanized interface or system (Shared Registration System between Tier 1Bs and the
1111   Tier 1A may not be required.




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


1112
1113   7.3       Interfaces between ENUM Tier 1B and ENUM Registrars
1114   Editor’s note – see separate document - registry and registrar interfaces
1115   This interface may be used by the ENUM Registrar to manage their account with the Tier 1 Registry
1116   [EDITOR”S NOTE - Need to further investigate/document the applicant‟s authentication requirements
1117   to be an ENUM Applicant]
1118
1119   7.4       Interfaces between ENUM Tier 1B and Tier 2 Registries
1120   This interface may be used by the Tier 1B Registry to discuss the DNS operation problems with the Tier 2 Provider
1121   if it is the technical contact for the ENUM domain name.
1122   Only the interface between the ENUM Registrar and the Tier 1B Registry is subject to formal standardization. The
1123   interface between the ENUM Registrar and the Tier 2 Provider may be subject to formal standardization if there is a
1124   strong interest to do so. The interface between the ENUM Registrar and the ENUM Registrant is likely to be
1125   defined by each ENUM Registrar. The interface between the ENUM Registrant and the Tier 2 Provider is likely to
1126   be defined by each Tier 2 Provider. The interface between the Tier 1B Registry and the Tier 2 Provider can be as
1127   simple as a telephone call or e-mail message about a DNS operation problem.
1128

1129   SECTION 8.0              PROVISIONING (SECTION REPLACED WITH REVISED TEXT)
1130
1131   This section defines provisioning requirements and procedures for ENUM administration. This involves
1132   the following ENUM functional entities: ENUM Registrar, ENUM Tier 1B Registry, Tier 2 Provider,
1133   Application Service Provider (ASP), and ENUM Registrant. This section will address the tasks and
1134   responsibilities required to provision and maintain ENUM registrations by the above functional entities
1135   with the focus on the interface between the Tier 1B Registry and the ENUM Registrar.
1136   This section does not include procedures for interaction with the Tier 1A Registry.
1137
1138   8.1       Assumptions
1139   The following assumptions are made when describing the provisioning scenarios:
1140            ENUM Registrars will be bound by a Registry-Registrar agreement developed by the Tier 1B
1141             Registry together with the LLC. This agreement will require the Registrar to comply with the
1142             procedures detailed below. In addition to the provisioning procedures, the Registry-Registrar
1143             agreement will detail privacy requirements based on those in Section 9 of ENUM Forum document
1144             6000_1_0 and registration dispute resolution procedures based on Section 14 of the ENUM Forum
1145             document.
1146            ENUM Registrars have an established trust relationship with the Tier 1B Registry. This
1147             relationship includes the method for secure communication, user authentication (e.g., the
1148             assignment of a user identification (ID) and password for session management), a Registrar ID for
1149             ENUM Registration identification, and exchange of contact and other information before ENUM
1150             registrations begin. How to open a secure communication link and establish a session between a
1151             Tier 1B Registry and an ENUM Registrar is not included in the provisioning procedures.

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


1152            An ENUM Registrar can offer Tier 2 Provider service. It can either operate the nameservers itself,
1153             or outsource the nameserver operation.
1154            The entity that serves as the Tier 1B Registry for a number cannot also serve as an ENUM
1155             Registrar. This stricture is intended to prevent conflicts of interest on the part of the Registry.
1156            An ENUM Registrant may authorize its Tier 2 Provider to review/update certain data (e.g., host
1157             and technical contact information) at its ENUM Registrar and/or its ASPs to review/update some
1158             application-related data for his/her ENUM domain name. The necessary data elements and
1159             procedures related to the interactions between the Tier 2 Provider and the ENUM Registrar, or
1160             between ASPs and Tier 2 Providers are not addressed in this document.
1161
1162   8.2       Provisioning Requirements
1163   This section lists, or cross-references, the high level requirements for the entities involved in provisioning
1164   the ENUM. In terms of provisioning for ENUM, more stringent and specific requirements will be placed
1165   on the Tier 1B Registry and the ENUM Registrars. The Tier 2 Provider, although still subject to certain
1166   requirements, will have more freedom to interact with ENUM Registrants, and optionally, with the ASPs
1167   and the ENUM Registrar in terms of the protocols and/or methods for interactions.

1168   8.2.1 Tier 1B Registry
1169   The Tier 1B Registry is responsible for properly identifying and authenticating a Registrar before
1170   accepting any transactions. The Tier 1B Registry is responsible for ensuring that Registrars comply with
1171   the requirements and procedures set out in the Registry-Registrar agreement and monitoring Registrar
1172   compliance.

1173   8.2.2 ENUM Registrar
1174   The ENUM Registrar must authenticate ENUM Applicants and verify their authorization to register an ENUM
1175   domain. In particular,
1176            When dealing with a corporate ENUM Registrant, only those specific persons who are the designated
1177             contact persons of the corporate account with the telephony service provider (TSP) can request ENUM
1178             registration for any TN used by that corporation.
1179          When a broker/agent is involved in applying for ENUM, the broker/agent must demonstrate authorization
1180           by the TN assignee/ENUM Registrant to register for ENUM.
1181   The Registry-Registrar agreement will contain minimum requirements for Authentication and Authorization
1182   building on those discussed in Section 12 of ENUM Forum Document 6000_1_0.
1183   The ENUM Registrar must support the protocols specified between the Tier 1 Registry and the ENUM Registrars.
1184   The protocols include those for application handling, secure communications, and lower-layer transport and routing.
1185   The ENUM Registrar must follow the policies specified for ENUM provisioning (e.g., various grace periods, if any,
1186   transfer and renewal).
1187   The ENUM Registrar should notify the technical contact associated with each ENUM domain name impacted by an
1188   area code split following the recommended procedures in Section 8.4.
1189   If the ENUM Registrar also offers the Tier 2 Provider function to the ENUM Registrant, it must support all the
1190   requirements a Tier 2 Provider must support. If it outsources those functions with a Tier 2 Provider, it must collect
1191   the NAPTR resource record (RR) information or sufficient information that allows that Tier 2 Provider to provision
1192   the NAPTR RRs from the ENUM Registrant.


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


1193   8.2.3 Tier 2 Provider
1194   The Tier 2 Providers that offer commercial service to other parties (as opposed to a Registrant providing a Tier 2
1195   solely for their own TNs) are expected to adhere to the Best Practices document to be developed by the Tier 1B
1196   Registry in conjunction with the LLC and participate in a certification process administered by the Tier 1B Registry.
1197   Commercial Tier 2 Providers must agree to host NATPRs for multiple ASPs and are prohibited from disclosing the
1198   any information they collect in the process of providing service. Non-commercial Tier 2 Providers must self certify
1199   themselves as such.

1200   8.2.4 ENUM Registrant
1201   The ENUM Registrant shall register only the TN or TNs assigned to them.
1202   The ENUM Registrant should inform the ENUM Registrar when he/she disconnects the telephony service (e.g., is
1203   no longer the TN assignee).
1204   If an ENUM Registrant operates the Tier 2 Provider function, it should also comply with the recommendations of
1205   the Tier 2 Provider Best Current Practices document.

1206   8.2.5 Application Service Provider (ASP)
1207   The ASPs must give the correct application addresses/URLs to the ENUM Registrant. They may interact with the
1208   Tier 2 Provider in provisioning certain data related to their application service when authorized by the ENUM
1209   Registrant.
1210   Some of the ASPs’ application services may require further resolution services, such as Lightweight Directory
1211   Access Protocol (LDAP) or other specific protocols to retrieve application-related information. In that case, ASPs
1212   must ensure that the correct information is provisioned in the NAPTR RRs stored at Tier 2 Providers.
1213
1214   8.3     Provisioning Procedures
1215   This section describes representative scenarios for ENUM Provisioning Activities. Additional scenarios are detailed
1216   in US ENUM Forum 6000_1_0. The Tier 1B Registry shall develop a comprehensive set of procedures, subject to
1217   LLC approval. The Registry shall implement the procedures agreed upon and incorporate then into the Registry-
1218   Registrar agreement.

1219   8.3.1   Initial ENUM Registration

1220   8.3.1.1 Assumptions
1221   An ENUM Applicant may either select a Tier 2 Provider prior to contacting an ENUM Registrar or
1222   contract with a Registrar that also provides Tier 2 services. In the later case, the Registrar will already
1223   have some of the information required for provisioning.

1224   8.3.1.2 Provisioning Procedures
1225           1. The ENUM Applicant selects an ENUM Registrar and provides the following information to that
1226              ENUM Registrar to register for ENUM for his/her TN:
1227                  TN
1228                  A list of nameserver host names associated with the ENUM domain name
1229                  ENUM registration period (e.g., two years)
1230                  ENUM Registrant's information and technical, administrative and billing contact
1231                   information

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


1232                 Any AAA-related information required by the ENUM Registrar
1233          2. The ENUM Registrar may interact with the ENUM Applicant for more information if needed. The
1234             ENUM Registrar then validates the ENUM Applicant’s identity and authority to register the TN. If the
1235             Applicant is not the assignee of the TN, the Registrar must verify that the Applicant is the duly
1236             authorized agent of the TN assignee. In this case the Registrar will collect contact information for both
1237             the agent and the TN assignee.
1238          3. If the validation fails, the application for ENUM is rejected. If the validation is successful, the process
1239             continues with step 4.
1240          4. The ENUM Registrar registers the ENUM domain name with the Tier 1B Registry by providing the
1241             following information:
1242                 Request for new ENUM domain name registration
1243                 ENUM domain name (e.g., 4.3.2.1.3.3.5.2.0.2.1.e164.arpa)
1244                 A list of nameserver host names
1245                 ENUM Registration period (e.g., two years)
1246                 The ContactInfo data elements defined in Section 5.5.5
1247          5. After successful authentication and authorization checks of the ENUM Registrar, the Tier 1B Registry
1248             determines whether there is an existing ENUM registration for the same ENUM domain name.
1249                 If YES, it initiates the dispute resolution process in the Registry-Registrar agreement and
1250                  this process stops.
1251                 If NOT, the Tier 1B Registry acknowledges to the ENUM Registrar that the ENUM domain name
1252                  registration is accepted with a registration expiration date. The Tier 1 Registry then performs the
1253                  zone file updates to add the NS RRs of this ENUM domain name to its nameservers. After the zone
1254                  file updates have been performed at the Tier 1 Registry, real-time DNS queries for this particular
1255                  ENUM domain name will be able to retrieve the nameserver information indicating where NAPTR
1256                  RRs are hosted.
1257                     After receiving the positive acknowledgement from the Tier 1 Registry, the ENUM
1258                      Registrar records this successful ENUM registration and may inform the ENUM
1259                      Registrant about the successful registration of his/her ENUM domain name.
1260
1261




                                                               39
                                                      Registrant selects
                                                           Tier 2

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

                                                        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
                                                      Registrant identity
             EN                                       and TN assignment
              D


                                                                    succeeds
                       dispute resolution             Registrar checks
                       process                  YES   for existing
                                                      registration for TN



                                                             no
                                                       Registrar sends
                                                         registration
                                                      request to Tier 1B
                                                           Registry




                                                          Registry
                                                        authenticates
                                                          Registrar



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


1262


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


1263                            FIGURE 2 – Flow Chart for 8.3.1.2: Initial ENUM Registration

1264   8.3.6 ENUM Registration Transfer
1265   ENUM Registrant transfers his/her ENUM registration to another ENUM Registrar.

1266   8.3.6.1 Assumptions
1267           ENUM Registrant uses the same Tier 2 Provider and the nameservers are the same.
1268           ENUM Registrant can initiate the transfer of the ENUM registration at any point during the term
1269            of the registration
1270           Note: it was agreed that registrations must be revalidated yearly

1271   8.3.6.2 Provisioning Procedures
1272   1.       The ENUM Registrant decides to use another ENUM Registrar for his/her ENUM registration and provides
1273   the following information to that ENUM Registrar:
1274           TN
1275           The ENUM Registrant's information and technical, administrative and billing contact information
1276       Any AAA-related information required by the ENUM Registrar
1277   2.      The ENUM Registrar may interact with the ENUM Registrant for more information if needed. The ENUM
1278   Registrar then validates the ENUM Registrant's identity and TN assignment .
1279            a.      If the validation fails, the request for transferring the ENUM registration is rejected and the transfer
1280            process stops.
1281            b.      If the validation is successful, go to Step 3.
1282   3.   ENUM Registrar requests that the Tier 1B Registry transfer the service registration for this particular
1283   ENUM domain name by providing the following information:
1284           Request for transferring an existing ENUM domain name
1285           ENUM domain name (e.g., 4.3.2.1.3.3.5.2.0.2.1.e164.arpa)
1286           ENUM Registration expiration date
1287           Any AAA-related information
1288
1289   4.     After successful authentication and authorization checks of the ENUM Registrar, the Tier 1B Registry
1290   determines whether there is an existing service registration for the ENUM domain name that can be transferred.
1291   a.      If YES, it puts the ENUM domain name in the “pending transfer” state and informs the old ENUM
1292   Registrar about the transfer.
1293   i.       If the Tier 1B Registry receives an acknowledgement from the old ENUM Registrar or times out for
1294   receiving an acknowledgement, it completes the transfer (e.g., the new ENUM Registrar is now the sponsoring
1295   Registrar) and changes the state of the ENUM domain name back to the “active” state. The Tier 1B Registry also
1296   notifies the new ENUM Registrar about the successful completion of the transfer request. The notification may be
1297   put in a queue for ENUM Registrars to retrieve.
1298   ii.     If the Tier 1B Registry receives a negative acknowledgement from the old ENUM Registrar, it will deny the
1299   transfer and the old and new ENUM Registrars and the ENUM Registrant will need to resolve this among
1300   themselves.
1301   b.       If NOT, the Tier 1B Registry rejects the transfer by indicating that the ENUM domain name does not exist.

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


1302   5.     After receiving the response from the Tier 1B Registry, the new ENUM Registrar performs the following:
1303   a.      If the transfer is complete, it puts the information associated with the transferred ENUM domain name in
1304   the local data stores. It informs the ENUM Registrant about the successful transfer and completes the necessary
1305   actions (e.g., collects the registration fee from the ENUM Registrant for the renewal period and pays the Tier 1B
1306   Registry).
1307   b.     If the old ENUM Registrar rejects the transfer, it informs the ENUM Registrant about the result and urges
1308   the ENUM Registrant to settle the matter with the old ENUM Registrar.
1309   c.      If the transfer is rejected due to the non-existence of the ENUM domain name, it informs the ENUM
1310   Registrant about the result.
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321




                                                              42
       Tier 1B Technical and Operational Requirements                      CC1 ENUM LLC TAC-12.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
1322                                     FIGURE 4 - Flow Chart for 8.3.6.2:
1323                     ENUM Registrant Transfers ENUM Registration to another Registrar
1324                                         8/19 Review stopped here

1325   8.3.7        ENUM Registrant Checks/Changes Information at the ENUM Registrar
1326   ENUM Registrant checks or changes information stored at the ENUM Registrar.
                                                           43
       Tier 1B Technical and Operational Requirements                         CC1 ENUM LLC TAC-12.00001-2005


1327   8.3.7.1            Assumptions
1328              The ENUM Registrant has already set up an account with the ENUM Registrar.
1329              The ENUM Registrant can check and make changes to all the information except the Telephone
1330               Number (TN) kept by the ENUM Registrar.
1331              The ENUM Registrant may initiate the changes himself/herself, or his/her action may be triggered
1332               by requests from the Tier 2 Provider if the ENUM Registrant is the only one that can deal with the
1333               ENUM Registrar.
1334              Some data changes/additions/deletions made by the ENUM Registrant at the ENUM Registrar
1335               need to be reflected at the Tier 1B Registry. It is assumed that if the ENUM Registrar approves
1336               and acts upon such a request the Tier 1B Registry will not deny that request.

1337   8.3.7.2 Provisioning Procedures
1338   1. The ENUM Registrant provides the authentication/authorization information and indicates the type of
1339   request with the associated information to the ENUM Registrar. The type of request and associated
1340   information may include:
1341               Check
1342                  1. Status of ENUM domain name registration
1343                  2.All or certain current values associated with the registered ENUM domain name account
1344                    such as:
1345                          Technical, administrative and billing contact information
1346                          Contact information for the account with the ENUM Registrar
1347                          Nameservers
1348                          Registration expiration date
1349               Add
1350                  o New nameserver
1351                  o Additional technical, administrative or billing contact information
1352                  o Additional Contact information for the account with the ENUM Registrar
1353                  o Authorization for the Tier 2 Provider to access its data stored at the ENUM Registrar, if not
1354                    previously authorized
1355               Delete
1356                  o Nameserver
1357                   Technical, administrative or billing contact information
1358                  o Contact information for the account with the ENUM Registrar
1359                  o Authorization of the Tier 2 Provider to access its data stored at the ENUM Registrar, if
1360                    previously authorized
1361               Modify/Change

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


1362              o User id, if permitted
1363              o Password
1364              o Technical, administrative or billing contact information
1365              o Registrant's contact information
1366              o Tier 2 Provider contact information
1367              o TSP account information such as the TSP name if ENUM Registrant ports his/her TN to a
1368                new TSP or billing address
1369   2. The ENUM Registrar validates the ENUM Registrant.
1370   3. If the validation fails, the ENUM Registrar rejects the request indicating authentication/authorization
1371      failure (e.g., invalid password).
1372   If the validation is successful, the ENUM Registrar proceeds with Step 4.
1373   4. The ENUM Registrar checks whether the requested action is valid.
1374        a) If the request is not valid, the ENUM Registrar rejects the request indicating the reason of
1375           rejection. Illegal requests include but are not limited to:
1376              o Change/modify data that the ENUM Registrant is not allowed to change/modify or does not
1377                exist
1378              o Delete data that does not exist or will result in missing mandatory data
1379              o Add data that the ENUM Registrant is not allowed to add or will exceed the maximum
1380                number allowed for that data
1381        b) If the request is valid, the ENUM Registrar performs required actions that include but are not
1382           limited to:
1383              o Returns the requested information, if available, or an indication that the requested
1384                information is not available
1385              o Replaces with data from the request and returns a positive acknowledgement
1386              o Deletes data and returns a positive acknowledgement
1387              o Adds data and returns a positive acknowledgement
1388        If the action of change/deletion/addition cannot be performed due to internal problems, the Registrar
1389        indicates "request pending" to the ENUM Registrant. After successful completion of the request, the
1390        Registrar sends a positive acknowledgement to the ENUM Registrant.
1391        The Registrar may inform the Tier 2 Provider if it is authorized by the ENUM Registrant to
1392        access/change certain data, and the ENUM Registrant has made changes to the data that the Tier 2
1393        Provider is authorized to change.
1394   5. The ENUM Registrar checks whether it needs to inform the Tier 1B Registry about the data change,
1395      deletion or addition, or to access the Tier 1B Registry for data status.
1396      If the ENUM Registrar need not inform the Tier 1B Registry about the data change, deletion, addition
1397      or to access the Tier 1B Registry for data status, the process stops.


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


1398      If the ENUM Registrar needs to inform the Tier 1B Registry about the data change, deletion or
1399      addition, it provides the authentication/authorization information and indicates the type of request with
1400      the associated information to the Tier 1B Registry.
1401   6. The Tier 1B Registry validates the ENUM Registrar.
1402      If the validation fails, the Tier B1 Registry rejects the request indicating authentication/authorization
1403      failure (e.g., invalid password). The ENUM Registrar, if valid, needs to resolve the problem (e.g., re-
1404      assign a password) with the Tier 1B Registry and resubmit the request.
1405      If the validation is successful, the Tier B1 Registry proceeds with Step 7.
1406   7. The Tier 1B Registry checks whether the requested action is valid.
1407      If the request is not valid (e.g., syntax error), the Tier 1B Registry rejects the request indicating the
1408      reason for rejection.
1409      If the request is valid, the Tier 1B Registry performs the required actions and returns a positive
1410      acknowledgement.
1411   8. ENUM Registrar returns the requested information if not yet done in step 4.




                                                           46
       Tier 1B Technical and Operational Requirements                CC1 ENUM LLC TAC-12.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

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


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


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

1416   8.3.9.1            Assumptions
1417            Only the checks/changes initiated by the ENUM Registrar are discussed. Checks/changes initiated
1418             by the ENUM Registrant and the Tier 2 Providers may be accomplished through the Registrar.
1419            The ENUM Registrar does not initiate a transfer request without the ENUM Registrant’s request

1420   8.3.9.2         Provisioning Procedures
1421   1. The ENUM Registrar provides the AAA-related information and indicates the type of request with the associated
1422   information to the Tier 1B Registry. Any information that is provided by this ENUM Registrar can be checked and
1423   changed by this ENUM Registrar. An ENUM Registrar may check some information (e.g., whether an ENUM
1424   domain name is available) even if the information is provided by other ENUM Registrars. The type of request and
1425   associated information may include:
1426            Check
1427                o     All or certain current information associated with the ENUM Registrant’s ENUM registration such
1428                      as:
1429                             Contact information
1430                             service registration expiration date
1431                             The last date when an object is created, modified or transferred
1432                             State of an object (e.g., active, server hold)
1433
1434                o     All or certain current information associated with the ENUM Registrar’s data such as:
1435                             Contact information
1436                             Organizational information
1437                             IP address(es)
1438                             [Web site address]
1439                             [ContactInfo server name]
1440                             Security pass phrase (for authenticating an ENUM Registrar when contacting the Tier 1B
1441                              Registry’s customer support by telephone)
1442                             User id and password information
1443
1444                o     Digital certificate information
1445            Add
1446                o     Additional ENUM Registrar Contact information
1447                o     Additional ENUM Registrar Organizational information
1448                o     Additional IP address(es)
1449                o     Additional user id and password
1450            Delete

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


1451                            Contact information
1452                            IP address(es)
1453                            ENUM Registrar user id and password, when there are multiple accounts
1454           Modify/Change
1455                          ENUM Registrar’s contact information, user id, password, security pass phrase, digital
1456                           certificate information, web site address
1457   2. The Tier 1B Registry validates the ENUM Registrar.
1458            a. If the validation fails, the Tier 1B Registry rejects the request indicating authentication/authorization
1459            failure (e.g., invalid password).
1460            b. If the validation is successful, the Tier 1B Registry proceeds with Step 3.
1461   3.       The Tier 1B Registry checks whether the requested action is valid.
1462            a.      If the request is not valid (e.g., syntax error), the Tier 1B Registry rejects the request indicating the
1463            reason for rejection.
1464            b.     If the request is valid, the Tier 1B Registry performs the required actions and returns a positive
1465            acknowledgement.
1466   4.       When a response is received, the ENUM Registrar performs the following:
1467            a.      If the request is rejected, it tries to determine the cause of the failure and re-submit the request, if
1468            needed, after the problem is cleared.
1469   b.       If the request is accepted, it makes the necessary changes/additions/ deletions in the local data stores.




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



                                                      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

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

1471    8.3.10       ENUM Registrant Renews ENUM Registration
1472   The ENUM Registrant renews his/her ENUM registration when the previous ENUM registration is to expire or
1473   when he/she decides to extend the service registration period at any time before the existing service registration
1474   expires.

1475   8.3.10.1          Assumptions
1476                     o The ENUM Registrant does not change the ENUM Registrar for the renewed
1477                       registration period.
1478                     o Host information associated with the ENUM domain name does not change.
1479                     o The ENUM Registrant will renew the service contract, if necessary, with the Tier 2
1480                       Provider. This process is not discussed.

1481   8.3.10.2        Provisioning Procedures
1482       1. The ENUM Registrant requests that the ENUM Registrar renew or extend the existing ENUM registration
1483       by providing the following information:
1484                 ENUM TN
1485                 Renewal period

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


1486           Any AAA-related information required by the ENUM Registrar for renewal.
1487      2. The ENUM Registrar then validates the ENUM Registrant's identity and the TN assignment as discussed in
1488      Section 8.2.2.
1489          a.     If the validation fails, the application for renewing the ENUM registration is rejected. The process
1490          stops.
1491      b. If the validation is successful, the ENUM Registrar proceeds with Step 3.
1492      3. The ENUM Registrar requests that the Tier 1B Registry renew the ENUM domain name by providing the
1493      following information:
1494              Request to renew ENUM registration.
1495              ENUM domain name (e.g., 4.3.2.1.3.3.5.2.0.2.1.e164.arpa).
1496              New ENUM Registration expiration date.
1497           Any AAA-related information required by the Tier 1B Registry.
1498      4. After successful authentication and authorization checks of the ENUM Registrar, the Tier 1B Registry
1499      determines whether there is an existing ENUM registration for the requested ENUM domain name.
1500          a.      If YES and the ENUM Registrar is the one who registered the ENUM domain name, the Tier 1B
1501          Registry acknowledges to the ENUM Registrar that the ENUM domain name registration is renewed with a
1502          new registration expiration date. The Tier 1B Registry then updates the data (e.g., new registration
1503          expiration date and date when renewal is done) in the local data stores.
1504          b.      Otherwise, the Tier 1B Registry rejects the request.
1505      5. After receiving the response from the Tier 1B Registry, the ENUM Registrar performs the following:
1506          a.       If the renewal is accepted, it updates information such as the service registration expiration date and
1507          the date the renewal is done in the local data stores. It informs the ENUM Registrant about the successful
1508          renewal and completes the necessary actions (e.g., collects the registration fee from the ENUM Registrant
1509          for the renewal period and pays the Tier 1B Registry).
1510          b.   If the renewal is rejected due to the non-existence of the ENUM domain name, it informs the
1511          ENUM Registrant about the result.
1512




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


                                                                              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

1513              FIGURE 8 – Flow Chart for 8.3.10.2: ENUM Registrant Renews ENUM Registration
1514

1515   8.3.11 ENUM Registrant Terminates ENUM Registration
1516   The ENUM Registrant terminates his/her ENUM registration before it expires.

1517   8.3.11.2      Provisioning Procedures
1518       1. The ENUM Registrant contacts the ENUM Registrar and indicates his/her desire to terminate
1519          registration for his/her ENUM domain name. The ENUM Registrant provides the following
1520          information:

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


1521                 ENUM TN
1522                 Request for terminating ENUM registration
1523                 Any AAA-related information required by the ENUM Registrar
1524      2. The ENUM Registrar checks if the request comes from the authorized ENUM Registrant.
1525                  If YES, the ENUM Registrar reminds the ENUM Registrant that terminating his/her
1526                  ENUM registration may cause associated addresses and services to no longer function as
1527                  before. Proceed to step 3.
1528                  If NO, the ENUM Registrar ends the termination process by indicating to the requester that
1529                  he/she is not authorized to terminate the service registration for the subject ENUM domain
1530                  name.
1531      3. The ENUM Registrar notifies the Tier 1B Registry about service termination by providing the
1532         following information:
1533             ENUM domain name
1534             Request for terminating ENUM
1535             Any AAA-related information required by the Tier 1B Registry
1536      4. The Tier 1B Registry notifies the ENUM Registrar that the registration for the subject ENUM
1537         domain name has been terminated. It then removes the ENUM registration for that ENUM domain
1538         name from its local data store and nameservers.
1539      5. The ENUM Registrar acknowledges the successful execution of the request to the ENUM
1540         Registrant.
1541      6. The responsible party arranges for removal of NAPTR records at the Tier 2 Provider:
1542          If the ENUM Registrar also provides the Tier 2 Provider function it removes the NAPTR records
1543          from its nameservers.
1544          If the ENUM Registrar uses a Tier 2 Provider, it notifies the Tier 2 Provider to terminate the
1545          service by removing the NAPTR records from its nameservers.
1546          If the ENUM Registrant had contracted for the Tier 2 Provider function directly, the ENUM
1547          Registrant notifies the Tier 2 Provider to terminate the service by removing the NAPTR records
1548          from its nameservers.
1549          If the ENUM Registrant provided the Tier 2 Provider function him/her/itself, the Registrant
1550          removes the NAPTR records from his/her/its nameservers.
1551      7. Notification of Application Service Providers (ASPs). The Registrant should notify the
1552         Registrant’s ASPs that the ENUM registration has been terminated if they are authorized to
1553         access/change the data at the Tier 2 Provider.
1554
1555




                                                          53
       Tier 1B Technical and Operational Requirements                            CC1 ENUM LLC TAC-12.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


1556        FIGURE 9 – Flow Chart for 8.3.11.2: ENUM Registrant Terminates ENUM Registration
1557

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


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

1561   8.3.12.1            Assumptions
1562      The ENUM Registrant does not inform the ENUM Registrar that he/she is no longer the TN assignee.
1563      The ENUM Registrar detects that the ENUM Registrant is no longer the TN assignee through the
1564       periodic re-validations or notification from the ENUM Registrant’s serving Telephony Service
1565       Provider (TSP).2

1566   8.3.12.2           Provisioning Procedures
1567              1.      The ENUM Registrar determines that the registration of an ENUM domain name should be
1568              terminated; it requests the Tier 1B Registry to delete the ENUM domain name by providing the following
1569              information:
1570                   o   Request to delete the ENUM registration.
1571                   o   ENUM domain name (e.g., 4.3.2.1.3.3.5.2.0.2.1.e164.arpa)
1572                   o  Any AAA-related information required by the Tier 1B Registry.
1573              2.      After successful authentication and authorization checks of the ENUM Registrar, the Tier 1B
1574              Registry determines whether there is an existing ENUM registration for the requested ENUM domain name.
1575                       a.     If YES, the Tier B1 Registry acknowledges to the ENUM Registrar that the ENUM domain
1576                       name registration is deleted. The Tier 1B Registry then removes information associated with the
1577                       ENUM domain name in the local data stores and updates the zone file.
1578                       b.     If NOT, the Tier 1B Registry rejects the request.
1579              3.       After receiving the response from the Tier 1B Registry, the ENUM Registrar
1580                        may inform the ENUM Registrant and the technical contacts associated with the ENUM domain
1581                       name about the termination of the ENUM registration .
1582
1583




       2 The ENUM Registrar may need to make contractual arrangements with the TSP to receive the
       notification.

                                                                  55
       Tier 1B Technical and Operational Requirements                            CC1 ENUM LLC TAC-12.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


1584
1585                 FIGURE 10: Flow Chart for 8.3.12.2: ENUM Registrant No Longer a TN Assignee
1586

1587   8.3.13 ENUM Registrar Terminates the ENUM Registration
1588   The ENUM Registrar terminates the ENUM Registrant’s service registration before the previous ENUM
1589   registration expires due to contractual business reasons. This can happen when the ENUM Registrant does not pay
1590   the ENUM Registrar the registration fee before the grace period, if any, of the ENUM registration (e.g., five days)
1591   expires. It may also happen if the ENUM Registrar determines that an ENUM registration is no longer valid (e.g.,
1592   as the result of the dispute resolution process).
1593   The provisioning procedures are exactly the same as those described in Section 8.3.12.


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


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

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

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

1606   8.4               Area Code Split
1607   An area code is split; the new area code is assigned to the same Tier 1B Registry that handles the old area
1608   code.

1609   8.4.1             Assumptions
1610             The Tier 1B Registry, the ENUM Registrars and the Tier 2 Providers that are involved with the
1611              telephone numbers (TNs) impacted by the area code split will take the necessary steps to support
1612              the area code split and the permissive dialing period3 whether the ENUM Registrant informs them
1613              about the area code split/TN change or not.
1614             The ENUM domain name that is associated with the TN under the old area code is referred to as
1615              the "old ENUM domain name." The ENUM domain name that is associated with the TN under
1616              the new area code is referred to as the "new ENUM domain name." For example, if the TN 703-
1617              434-1234 has registered for ENUM and is to be changed to 571-434-1234, the old ENUM domain
1618              name would be "4.3.2.1.4.3.4.3.0.7.1.e164.arpa," and the new ENUM domain name would be
1619              "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) is referred
1620              to as the "old TN," and the TN under the new area code (e.g., 571-434-1234) is referred to as the
1621              "new TN."
1622             Only the ENUM domain names that are associated with the TNs impacted by the area code split
1623              (those that are to be changed to the new area code) are discussed. ENUM domain names that are
1624              not impacted by the area code split are handled by the usual procedures. For example, if 703-538-
1625              6789 is not subject to the area code change, its associated ENUM domain name,
1626              9.8.7.6.8.3.5.3.0.7.1.e164.arpa, will remain the same.




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


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


1627            T1 is the time (e.g., 12:01am EST on 6/1/01) when the new area code (e.g., 434 split from the old
1628             area code 804) becomes effective and the permissive dialing period begins. T2 is the time (e.g.,
1629             12:01am EST on 1/15/02) when the permissive dialing period ends.
1630            Normally an area code split involves only the area code change; however, it may happen that both
1631             the area code and the office code of a TN are changed. When an area code change is mentioned
1632             in this document, it also covers the case when both the area code and the office code are changed.
1633             In very rare cases, an area code split may be done based on a geographical boundary (e.g., a
1634             country line), which may result in a situation of "partitioned NPA-NXX." Some TNs in an NPA-
1635             NXX are changed to the new area code, while others remain in the old area code. Further study
1636             will determine how specific TNs under a partitioned NPA+NXX code can be obtained from
1637             telephony service providers (TSPs) since only the serving TSP of a TN knows whether that TN is
1638             impacted by the area code split. It may also be possible, although this is unlikely, to directly verify
1639             with the ENUM Registrant whether his/her TN is impacted by the area code split.
1640            The Tier 1B Registry shall monitor the The North American Numbering Plan Administrator
1641             (NANPA) website (http://www.nanpa.com) for impending area code splits, and use other
1642             information sources (e.g., the "area code split exchange diskette" from Telcordia
1643             (http://www.trainfo.com) as needed to maintain an up-to-date list of the affected NPA-NXX codes
1644             for a particular area code.

1645   8.4.2            Provisioning Procedures

1646   8.4.2.1          Procedures/Guidelines for a Tier 1B Registry with a Permissive Dialing Period
1647   One week before T1, the Tier 1B Registry shall send an e-mail message to each associated ENUM
1648   Registrar about the area code split and to remind it to take the appropriate actions required by the area
1649   code split.
1650   At no time before the T1 shall the Tier 1B Registry accept any request on any new ENUM domain name
1651   from the ENUM Registrar. This is because the new TN under the new area code is not yet effective
1652   before T1.
1653   Starting at T1, the Tier 1B Registry shall be capable of accepting and responding to any request made on
1654   the new ENUM domain name from the ENUM Registrar, and shall perform data updates on the local data
1655   stores and zone files, if applicable.
1656   The Tier 1B Registry shall not accept any request on any old ENUM domain name from the ENUM
1657   Registrar during the permissive dialing period.
1658   At T1, the Tier 1B Registry shall perform zone file updates to add all the new ENUM domain names.
1659   One, or more than one, new zone files may be created, or new data is added, to the existing zone file for
1660   those new ENUM domain names with exactly the same nameserver information copied from those
1661   associated with the corresponding old ENUM domain names at T1.4 The Tier 1B Registry shall not
1662   remove the Nameserver (NS) RRs associated with the old ENUM domain names from the existing zone
1663   file(s).



       4The new and old ENUM domain names may or may not be in the same zone file depending on how the
       zones are cut/delegated.

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


1664   The Tier 1B Registry should progressively reduce the Time to Live (TTL) values for the resource records
1665   associated with the old ENUM domain name so that such records will not persist in resolver caches
1666   beyond T2.
1667   The TTL in the NS RRs associated with the new ENUM domain name is set to a typical value (e.g., from
1668   a day to a week) depending on the Tier 1B Registry policy (e.g., frequency of zone file updates).
1669   Within twenty-four hours after T1, the Tier 1B Registry shall update its stored information to reflect the
1670   area code change on all the TNs. It shall search the local data stores and change all the TNs that are
1671   subject to the area code change, not just those that are associated with the old ENUM domain names. This
1672   will change all the phone numbers and fax numbers in the contact information of all the records.
1673   The Tier 1B Registry shall not accept any request (e.g., create, check, update, renew or transfer) on any
1674   old ENUM domain name during the permissive dialing period while it maintains records associated with
1675   the old ENUM domain name.
1676   The Tier 1B Registry shall keep the nameserver information in the zone file, and information in the local
1677   data stores associated with each new ENUM domain name, synchronized with those associated with the
1678   corresponding old ENUM domain name during the permissive dialing period. Any update request on the
1679   new ENUM domain name that is received from the ENUM Registrar during the permissive dialing period
1680   shall cause the same update on the old ENUM domain name. This includes the data in the ContactInfo
1681   database in case there are inquires about the ContactInfo information on the old ENUM domain names.
1682   Because of this need for data synchronization, it is highly recommended that the same Tier 1B Registry
1683   handle both the old and new area codes when there is an area code split.
1684   During the permissive dialing period, if the Tier 1B Registry receives a create request for an ENUM
1685   domain name that is available (e.g., no record exists for this ENUM domain name) and the associated TN
1686   is a new TN due to an area code split, it shall create a record for the old ENUM domain name in addition
1687   to the record for the new ENUM domain name.
1688   At T2, the Tier 1B Registry shall perform zone file updates to remove the NS RRs associated with the old
1689   ENUM domain names. It shall remove all the records associated with the old ENUM domain names from
1690   the local data stores.
1691   After the permissive dialing period expires, the Tier 1B Registry shall expect new ENUM registrations on
1692   the old ENUM domain names because the associated TNs can be reassigned to new telephony subscribers.
1693   Within twenty-four hours after T2, the Tier 1B Registry should send an e-mail message to each technical
1694   contact and ENUM Registrant that is associated with each old ENUM domain name to remind them to
1695   update the zone file(s) by removing any RR in the zone file and the data in the local data stores that is
1696   associated with the old ENUM domain name.

1697   8.4.3         Procedures/Guidelines for a Tier 1B Registry without a Permissive Dialing Period
1698   Since there is no permissive dialing period, T1 and T2 are the same. T1 in this case is the time when the
1699   new TN must be dialed and the old TN must not be dialed.
1700   One week before T1, it is recommended that the Tier 1B Registry send an e-mail message to each
1701   associated ENUM Registrar about the area code split and to remind them to take the appropriate actions
1702   required by the area code split.
1703   At no time before T1 shall the Tier 1B Registry accept any request on any new ENUM domain name from
1704   the ENUM Registrar. This is because the new TN under the new area code is not yet effective before T1.

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


1705   The Tier 1B Registry should progressively reduce the Time to Live (TTL) values for the resource records
1706   associated with the old ENUM domain name so that such records will not persist in resolver caches
1707   beyond T1.
1708   At T1, the Tier 1B Registry shall perform zone file updates to change all the old ENUM domain names to
1709   the new ENUM domain names while keeping the nameserver information unchanged. This can also be
1710   done by adding the NS RRs for the new ENUM domain names and removing those associated with the old
1711   ENUM domain names when dynamic updates are done. The TTL in the NS RRs associated with the new
1712   ENUM domain names should be set to a typical value (e.g., from a day to a week) depending on the Tier 1
1713   Registry policy (e.g., frequency of zone file updates).
1714   Starting at T1, the Tier 1B Registry shall be capable of accepting and responding to any request made on
1715   the new ENUM domain name from the ENUM Registrar and shall perform data updates on the local data
1716   stores and zone files, if applicable.
1717   Within twenty-four (24) hours after T1, the Tier 1B Registry shall update its stored information to reflect
1718   the area code change on all the TNs. It shall search the local data stores and change all the TNs that are
1719   subject to the area code change, not just those that are associated with the old ENUM domain names. This
1720   will change all the phone numbers and fax numbers in the contact information of all the records.
1721   After T1, the Tier 1B Registry shall expect new ENUM registrations on the TNs under the old area code
1722   because the associated TNs can be reassigned to new telephony subscribers.

1723   8.4.4   Procedures/Guidelines for an ENUM Registrar with a Permissive Dialing Period
1724   The ENUM Registrar should be aware of any area code split and the associated T1 and T2 that impacts the
1725   ENUM domain names registered through it. The Tier 1B Registry will notify Registrars of impending
1726   area code splits.
1727   One week before T1, it is recommended that the ENUM Registrar inform the ENUM Registrant, based on
1728   the Registrant contact information, about the changes of the ENUM domain name and the contacts' phone
1729   numbers and/or fax numbers for each old ENUM domain name. If it has the technical contact information
1730   or if it deals with the Tier 2 Provider, the ENUM Registrar should send an e-mail message to each
1731   technical contact or the contact person of the Tier 2 Provider to remind him/her to update the zone file(s)
1732   by adding the NS RRs and the Naming Authority Pointer (NAPTR) RRs for the new ENUM domain name
1733   before T1 and to leave the NS RRs and the NAPTR RRs associated with the old ENUM domain names in
1734   the existing zone file(s) until the permissive dialing period expires.
1735   At no time before T1 may the ENUM Registrar accept any request on any new ENUM domain name from
1736   the ENUM Registrant, nor shall they submit any request on any new ENUM domain name to the Tier 1B
1737   Registry.5
1738   Within twenty-four hours after T1, the ENUM Registrar shall update its stored information to reflect the
1739   area code change on all the TNs. It shall search the databases and change any TN that is subject to the
1740   area code change. This will change all the phone numbers and fax numbers in the contact information in
1741   all the records.




       5The ENUM Registrar could accept the requests and wait until T1 to submit the requests to the Tier 1B
       Registry, or it could submit the requests using the old ENUM domain names before T1.

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


1742   It is recommended that the ENUM Registrar verify with the ENUM Registrant, or the Tier 2 Provider if it
1743   is allowed to access/update data, whether a telephone number is correct when it receives a request during
1744   the permissive dialing period to add a phone or fax number or to change to a phone or fax number that is
1745   in a NPA-NXX subject to an area code change due to an area code split.
1746   Starting at T1, the ENUM Registrar shall be capable of accepting and responding to any request made on
1747   the new ENUM domain name from the ENUM Registrant, and shall perform data updates on the local
1748   data stores and the Tier 1B Registry, if applicable.
1749   The ENUM Registrar shall stop accepting any request on any old ENUM domain name during the
1750   permissive dialing period. If the ENUM Registrar receives any request on the old ENUM domain name
1751   from the ENUM Registrant during the permissive dialing period, it should inform the ENUM Registrant
1752   about the change to the new ENUM domain name due to an area code split. It shall also inform the
1753   ENUM Registrant and/or the technical contact to have the NAPTR RRs that are associated with both the
1754   new and old ENUM domain names in the Tier 2 Provider's nameservers.
1755   During the permissive dialing period, if the ENUM Registrar receives a new registration for an ENUM
1756   domain name that is available (e.g., no record exists for this ENUM domain name) and the associated TN
1757   is a new TN due to an area code split, it shall submit a create request on the new ENUM domain name and
1758   shall inform the ENUM Registrant and/or the technical contact to have the NAPTR RRs that are
1759   associated with both the new and old ENUM domain names in the Tier 2 Provider's nameservers.
1760   The ENUM Registrant may inform the ENUM Registrar about the TN change whether it is related to the
1761   ENUM domain name or any phone or fax number. The ENUM Registrar can confirm/ignore the update
1762   request if the change has been made automatically and may double check whether the change has been
1763   made correctly.
1764   After the permissive dialing period expires, the ENUM Registrar shall expect new ENUM registrations on
1765   the old ENUM domain names because the associated TNs can be reassigned to new telephony subscribers.
1766   Within twenty-four hours after T2, the ENUM Registrar should send an e-mail to each technical contact
1767   and ENUM Registrant that are associated with each old ENUM domain name to remind them to update
1768   the zone file(s) by removing any RR in the zone file and the data in the local data stores that are associated
1769   with the old ENUM domain name.
1770

1771   8.4.5          Procedures/Guidelines for an ENUM Registrar without a Permissive Dialing Period
1772   The ENUM Registrar should be aware of any area code split and the associated T1 that impacts the
1773   ENUM domain names registered through it. The Tier 1B Registry will notify Registrars of impending
1774   area code splits.
1775   One week before T1, it is recommended that the ENUM Registrar inform the ENUM Registrant, based on
1776   the Registrant contact information, about the changes of the ENUM domain name and the contacts' phone
1777   numbers and/or fax numbers for each old ENUM domain name. If it has the technical contact information
1778   or if it deals with the Tier 2 Provider, the ENUM Registrar should send an e-mail message to each
1779   technical contact or the contact person of the Tier 2 Provider to remind him/her to update the zone file(s)
1780   by adding the NS RRs and the NAPTR RRs for the new ENUM domain name, and by removing those
1781   RRs associated with the old ENUM domain name at T1.



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


1782   At no time before T1 may the ENUM Registrar accept any request on any new ENUM domain name from
1783   the ENUM Registrant; nor shall they submit any request on any new ENUM domain name to the Tier 1B
1784   Registry.
1785   Within five minutes after T1, the ENUM Registrar shall update its stored information to reflect the area
1786   code change on all the TNs. It shall search the databases and change any TN that is subject to the area
1787   code change. This will change all the phone numbers and fax numbers in the contact information in all
1788   the records.
1789   It is recommended that the ENUM Registrar verify with the ENUM Registrant, or a Tier 2 Provider if it is
1790   allowed to access/update data, whether a telephone number is correct when it receives a request within one
1791   month after T1 to add a phone or fax number or to make a change to a phone or fax number that is in a
1792   NPA+NXX subjecting to an area code change due to area code split.
1793   Starting at T1, the ENUM Registrar shall be capable of accepting and responding to any request made on
1794   the new ENUM domain name from the ENUM Registrant, and shall perform data updates on the local
1795   data stores and the Tier 1B Registry, if applicable.
1796   The ENUM Registrant may inform the ENUM Registrar about the TN change whether it is related to the
1797   ENUM domain name or any phone or fax number before or after T1. The ENUM Registrar can
1798   confirm/ignore the update request if the change has been made automatically and may double check
1799   whether the change has been made correctly.
1800   After T1, the ENUM Registrar shall expect new ENUM registrations on the old ENUM domain names
1801   because the associated TNs can be reassigned to new telephony subscribers.
1802

1803   SECTION 9.0           DISPUTE RESOLUTION
1804
1805




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


1806   Document Issues List:
1807   5-25-05
1808      Bidders need to address how they will comply with privacy and other regulations (ContactInfo) where they
1809       either store the data or if required where the data is originated. Example – CA privacy regulations differ from
1810       other states.
1811      System ready date – for vendor implementation timeline end point, and will also be the start of the Beta period,
1812       which will need to be determined in order to identify commercial start date.
1813      Turn up testing timeline / requirements for registrars and integration into system ready timeline process
1814      Need to have vendor notified that they need to prepare and be compliant with future relevant standards and
1815       national legal/regulatory obligations. When new standard published, vendor needs to notify LLC and present
1816       and implementation plan within 30 days of that notification.
1817      Need to specify / outline future system change management process for bidder
1818      Need agreement technical details developed for the following:
1819             Tier 1A Registry – CC1 ENUM LLC Agreement
1820             Tier 1B Registry US portions of the NANP – CC1 ENUM LLC Agreement for the US
1821             Tier 1B Registry all other NANP Countries – Party to be determined by each NANP country
1822             Tier 1B Registry – ENUM Registrar’s Agreement (Defined by contracting entity and embodied in an
1823             agreement)
1824
1825      Need clear statement that Tier 1B can not function also as a registrar.
1826      Tier 1B will develop the registrar accreditation and registrar agreement process, subject to the approval of the
1827       ENUM LLC and the appropriate regulatory authority.
1828
1829   6-9-05
1830   Editors Note: Need to specify all Agreements and their Title – this is not necessarily and all inclusive list:
1831             Tier 1A Registry – CC1 ENUM LLC Agreement
1832             Tier 1B Registry US portions of the NANP – CC1 ENUM LLC Agreement for the US
1833             Tier 1B Registry all other NANP Countries – Party to be determined by each NANP country
1834             Tier 1B Registry – ENUM Registrar’s Agreement (Defined by contracting entity and embodied in an
1835             agreement)
1836   [Infrastructure ENUM issues are TBD].
1837   Editor’s Note: Need contributions on Registry Database and SRS sections to clarify functionality and
1838   requirements
1839   (Editor’s Note – bidders to respond with details on physical facilities that will be provided to support SLR’s)
1840   (Editors Note: Physical location of the Tier 1B facilities must be within a NANP member country’s borders.)
1841   Editor’s Note: Need to address Geographic and network diversity requirements and tie it to SLRs. Network
1842   diversity is more important that geographic distribution.


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


1843   Acton Item: Effective dates for registrations (thick registry model) Need information on the effective
1844   end date, start stop dates or what is the length of registration period
1845   Transaction Signatures (TSIG), as described in RFC 2845, will be used for any/all data transmission between
1846   ENUM Tier 1B Registry and Tier 2 nameservers. (Note need to ensure TSIG is addressed in new provisioning
1847   section)
1848
1849
1850




                                                           64

				
DOCUMENT INFO