ICANN ICANN Email List Archives


<<< Chronological Index >>>    <<< Thread Index >>>

Depository, Inc. Response to ICANN Request for Consultation - INR

  • To: iana-kpis@xxxxxxxxx
  • Subject: Depository, Inc. Response to ICANN Request for Consultation - INR
  • From: peter.thimmesch@xxxxxxxxxxxxxx
  • Date: Tue, 11 Dec 2012 19:08:46 -0500

Mr. Vegoda,

Please find attached and embedded below Depository, Inc.'s response to ICANN's Request for Consultation on Internet Number Resources Performance Standards. Thank you for the opportunity to share our thoughts and this important matter. Please contact me at peter.thimmesch@xxxxxxxxxxxxxx if you have any questions regarding our submission.


December 11, 2012


Depository, Inc. (Depository) is pleased to submit a response to the Internet Corporation for Assigned Names and Numbers’ (ICANN) request for Consultation on Internet Number Resources Performance Standards. Depository is an independent Internet number registry providing an array of value-added Internet number registry services to our customers. As such, Depository and our customers are “interested and affected parties,” as defined in Sections C.1.3 and C.2.8 of Contract SA1301-12-CN-0035 (the “Contract”) between ICANN and the Department of Commerce (DoC), National Telecommunications Information Administration (NTIA). Depository is one of thousands of ICANN-community stakeholders, including tens of thousands of Legacy IPv4 number block owners, whose voices have been ignored until now by the current Internet Number Resources (INR) scheme. Depository applauds ICANN for following through with its contractual obligation under C.2.8 of the Contract and hopes ICANN will seriously consider ideas of all “interested and affected parties” to improve and expand the INR system for all stakeholders.

ICANN’s request for consultation deals with Performance Standards for allocation services only within the INR system. Allocation is an important activity to be sure, but it is not the only function performed in the INR system and is not the only function that should be included in the Key Performance Indicators (KPIs). Other functions currently performed by five Regional Internet Registries (RIRs) under minimal or no oversight by ICANN are:

•       Directory Services (WHOIS).
•       DNS delegations (and aggregation) for in-addr.arpa.
•       in-addr.arpa DNS resolution for parts of in-addr.arpa.
•       Routing policy publication.
•       Routing security services (RPKI).

To further punctuate the need for KPIs for post-allocation services, soon the allocation function will no longer be necessary for IPv4, but at the rate of IPv6 adoption, IPv4 will continue to need post-allocation services for many years to come. It is with this fact in mind that Depository addresses Questions 2 and 4 of the request for consultation. Depository respectfully puts forth suggested immediate actions and Performance Standards or reporting metrics in the areas of contracts, competition, documentation, accuracy, transparency, and process quality.


The key to ensuring compliance with any Performance Standard or metric devised lies in contract. Allocation and post-allocation services are conducted currently only by five independent RIRs who are not under contract with ICANN or any other authoritative party, including the DoC/NTIA, to do what they do. They are all private companies with their own interests that may or may not align with the interests of the entire stakeholder community. Therefore, no meaningful Performance Standards can be made to apply to them under the current paradigm even if they are agreed to by the “community” and implemented herewith by ICANN. It is a false assumption and misunderstanding of the current INR structure to believe otherwise. To address this, Depository recommends the following with respect to contracts:

• ICANN shall promptly develop a Registry/Registrar model for the INR similar to the model employed for DNS. Registrars shall be allowed to provide services without connectivity as a requirement. • ICANN shall collect from the Registry/Registrars and report all metrics similar to those already established for the DNS model, including, but not limited to aggregate details on Internet numbers under contracts with Registrars versus numbers not under contract with Registrars (i.e., Legacy IPv4 number block owners). • ICANN shall report metrics on any contracts for the update and maintenance of resolution related to Internet numbers (in-addr.arpa, etc.). • ICANN shall report metrics on any IANA Functions services delegated to third parties, but not under formal contract with ICANN, such as ICANN’s responsibility to update the IANA Registries. • ICANN’s goal shall be to have reporting on 100% of the contracted and non-contracted IANA Functions.


ICANN shall establish, maintain, and report metrics on progress towards competition amongst Registrars for allocation and post-allocation services consistent with ICANNs charter to foster competition in Internet numbers. The metrics shall include, but not be limited to:

•       Number of Registrar applicants from each region.
•       Number of active Registrars in each region.
•       Transfers of number blocks between Registrars.
•       Transfers of number blocks between Legacy IPv4 number block owners.
•       Name of all Registrars.
• Other competition metrics similar to those currently captured in the DNS Registrar model.
Metrics goals shall be to:

• Track and monitor satisfaction of all “interested and affected parties” with the Registrars and the services they offer. • Provide the Internet community, which ICANN serves, with information and resources to assist in choosing a Registrar providing services that meets their business needs.


ICANN shall ensure all INR community processes, procedures, and policies are clearly documented in a consistent manner. This level of documentation coverage should be tracked as a KPI of ICANN. The clear documentation shall be developed and implemented for:

•       Conflicts of interest, where present, and special interests.
•       Updating of the IANA WHOIS.
•       Updating of the InterNic WHOIS.
•       Data Escrow and Data Escrow Agreements.
•       Bulk Access.
•       Zone File Access.
•       Reserved Numbers.
•       Registrar service levels.
•       Number block restrictions.
•       Dispute resolution.


Directory Service (WHOIS) accuracy should be tracked as a KPI, including both IANA WHOIS and other WHOIS. Allocation data, including accounting of IP number gaps, should be accurate. The Registry should report performance indicators on the amount of space being used that is not authorized. All relevant TLDs should have a Registry provider. Accuracy should be defined as any contact information or company’s name that is not factually correct. In the case of the current IANA WHOIS of 256 records, over 70% indicate incorrect information.


Content on the ICANN website should be consistent with established processes, procedures, and policies. All contracts should be publically available for the operations and maintenance of .arpa, including ip6.arpa and in-addr.arp. Information about any IANA Functions not under formal contract with ICANN should also be publicly disclosed. This disclosure should explain the reason for the lack of a formal contract to carry out the function.

Timeliness & Process Quality

ICANN shall report on the service levels and quality for all processes and procedures, including, but not limited to:

•       Response times on IP number allocation requests.
• Numbers of approvals and numbers of denials for IP number requests. If denials, reasons for the denials. • Number of registry update requests; time to update record upon receipt of update request.
•       Details on performance of updates to routing policy, reverse lookups, 
•       Queries per second for in-addr.arpa.
•       Average response time for DNS resolution.
•       Percentage up time and down time for provided services.


The crisis looming for the INR community has eclipsed the crisis that once faced the DNS world. While the biggest Internet asset many Internet community members have is their IPv4 number block(s), they do not currently have the infrastructure and support they need to ensure security in their asset(s) and the iron-clad ability to use them without interruption to grow their business. The metrics, such as they are, and the Performance Standards in place today are woefully inadequate to continue to provide a robust and vibrant INR system. While IPv6 may be a long term solution, the prohibitive cost of dual stacking for many businesses will leave them looking for other alternatives in the IPv4 protocol for many, many years to come. It is ICANN’s charter and ICANN’s obligation under its Contract with the DoC to establish a framework for the management of IPv4 numbers that works for all “interested and affected parties.” Performance Standards is just one part of that framework.

Description: Adobe PDF document

<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy