[ga] GA_ISSUE-001: Domain Tasting | 10% AGP Cap Proposal - Analysis

["Dominik Filipp" <dominik.filipp@xxxxxxxx>]

Current Final 10% AGP Cap Proposal, the 'Motion 2' in the following
document

http://gnso.icann.org/mailing-lists/archives/council/msg04981.html


-----------------------------------
Vulnerability Stress Test Analysis
-----------------------------------

1. "1. a. During any given month, an Applicable gTLD Operator may not
offer any refund to a registrar for any domain names deleted during the
AGP that exceed (i) 10% of that registrar's net new registrations in
that month (defined as total new registrations less domains deleted
during AGP), or
(ii) fifty (50) domain names, whichever is greater."


1.1. Estimation of Actual Number of Domains
     [actual status]

According to the 1. a. provision above the number of domains that
qualify for for-free deletes within AGP is

MAX(50, x)

where x is a maximum number of domains deleted during AGP for free
conforming to the 1. a. 10% clause.
Given that TNR is the number of total net new registrations during a
given month and y is a number of domains deleted within AGP for free
during the month then the following formulas are valid

y <= 0.1 * (TNR - y), which gives
y <= 0.1 * TNR / 1.1

the maximum number x is then

x = 0.1 * TNR / 1.1            (1)

During the time period 03/24/08 - 04/28/08 the TNR for gTLDs was

For .COM domains
(the 'Net' column on the page below counted up through weeks)
(http://www.webhosting.info/registries/reports/domains/COM)
TNR(.COM) = 1245938 domains

For .NET domains
(http://www.webhosting.info/registries/reports/domains/NET)
TNR(.NET) = 107053 domains

For .ORG domains
(http://www.webhosting.info/registries/reports/domains/ORG)
TNR(.ORG) = 113850 domains

For .INFO domains
(http://www.webhosting.info/registries/reports/domains/INFO)
TNR(.INFO) = 44351 domains

For .BIZ domains
(http://www.webhosting.info/registries/reports/domains/BIZ)
TNR(.BIZ) = 16345 domains

The TNR collectively is

TNR = 1527537

It is to say that TNR are net new registrations (including 'brand' new
registrations as well as 'gained by transfer') and are not significantly
affected by domain tasting thus expressing domains properly registered
and retained in possession.

Given the TNR and using (1), x = 138,867.
That is, during the month 03/24/08 - 04/28/08 approximately 138,000
domains would be available for free deletes during AGP altogether.

If, however, only net 'brand' new registrations were considered, after
reviewing the 10 biggest registrars to find out the ratio, it gives
roughly 90% of all net gained domains, which gives approximately 125,000
applicable for free deletes during AGP.

--------------

1.2. 10% AGP Cap Is Too High [abuse-tendency vulnerability]

The 10% provision allows for a large number of domains to be deleted for
big registrars. For example, during 03/24/2008 - 04/14/2008 the number
of net new domains for 10 fastest growing registrars were
(http://www.webhosting.info/registrars/fastest-growing-registrars/global
/)

Registrar           Net New     10% Cap
---------------------------------------
GO DADDY            1,264,120   114,920
ENOM                  390,317    35,483
TUCOWS                212,028    19,275
SCHLUND+PARTNER       178,162    16,197
MELBOURNE IT          166,516    15,138
WILD WEST DOMAINS     127,695    11,609
NETWORK SOLUTIONS     120,103    10,918
MONIKER                89,819     8,165
PUBLIC DOMAIN REGISTRY 82,960     7,542
REGISTER.COM           72,437     6,585

The question is why big and well-developed registrars need such amount
of domains at their free disposal? And for what purpose exactly?
None or insufficient evidence has been collected to support the
legitimacy of the numbers.

--------------

1.3. Term 'Net new registrations'
     [ambiguous-term-interpretation vulnerability]

The term 'net new registrations' is not properly clarified. Do net new
registrations mean 'brand' net new registrations, or also net new
registrations gained by domain transfer? If both meanings are valid then
the 10% AGP cap limit can be overcome. A possible abuse related to it
could be called Bouncing-Transfers Abuse.

BOUNCING-TRANSFERS ABUSE (case study, simplified example)

Three necessary preconditions are:
- - -
a) The term 'Net new registration' also means net new registration
   gained by domain transfer.

b) A registrar company COMP owns at least four affiliate registrars
   R1, R2, R3, and R4, where

   - R1 is an 'empty' registrar (does not contain any domain
registration)
   - The R2, R3, R4 registrars contain 220,000 .COM domains each,
     manipulable at COMP's sole discretion (private registrar domain
     portfolio);
   - All R2, R3, R4 domains are older than 60 days to allow for domain
     transfer.

c) None registrar will register any new domain for any registrant.
- - -

Q: How many domains the company COMP can afford to delete during AGP for
free during any given month?

Applying the formula (1) mentioned in the paragraph 1. on our case-study
example gives x = 0. The resulting maximum number of domains deleted
during AGP for free is thus max(50, 0) = 50 for each registrar R1-R4.
The correct answer should be 50. Is it right?

No, the result is wrong. The company can taste 20,000 domains during AGP
for free every month! How is that possible?

1. Month M. Few days before end of month M 220,000 domains from R2 are
   actually transferred to R1. The TNR for R1 in this month is thus
220,000,
   using (1) gives x = 20,000 and max(50, 20000) = 20,000.

2. Month M + 1. Few days before end of month M + 1, 220,000 domains from
R3
   are actually transferred to R2, which again gives 20,000 domains for
   free AGP deletes for this month, this time in R2.

3. Month M + 2. Few days before end of month M + 2, 220,000 domains from
R4
   are actually transferred to R3. This again gives 20,000 domains for
   free AGP deletes for this month, this time in R3. What is very
important,
   the 220,000 domains in R1 are now transferable as the 60-day
non-transfer
   period has just elapsed for the names in R1.

The three points mentioned above define a basic 'quarterly' cycle of
abuse. As of 4. month the cycle starts from the beginning, however,
starting now with 'empty' registrar R4 to which domains from R1 will be
transferred in the next first step (month M + 3). This scheme, somewhat
resembling Round-Robin scheme, allows for fluent abuse based on bouncing
speculative domain transfers, without need to actually register any
single new domain.

Note
This sort of abuse is particularly suitable for big tasting/speculative
companies running several or many phantom registrars on background, such
as SnapNames or eNom.

FIX: This abuse can be eliminated by specifying the term 'net new
registrations' as being 'net brand new registrations' only, and not new
registrations gained by transfer.


* * * * * * * * * * * *

2. "1.b. A Registrar may seek an exemption from the application of such
restriction in a specific month, upon the documented showing of
extraordinary circumstances. For any Registrar requesting such an
exemption, the Registrar must confirm in writing to the Registry
Operator how, at the time the names were deleted, these extraordinary
circumstances were not known, reasonably could not have been known, and
were outside of the Registrar's control. Acceptance of any exemption
will be at the sole reasonable discretion of the Registry Operator,
however "extraordinary circumstances" which reoccur regularly will not
be deemed extraordinary."


2.1 Extraordinary Circumstances
    [subjective-interpretation, conflict-of-interests vulnerability]

'Extraordinary Circumstances' are not specified thus allowing for
subjective interpretation, consideration and application. Acceptance of
circumstances by Registries can lead to biased and benevolent positions
towards Registrars as both bodies participate in the same business.
Intentionally skewed reports regarding the specification of reasons
granting extraordinary circumstances sent to ICANN are likely/possible
in such circumstances.

A significant concern related to extraordinary circumstances is an
unknown specification/information about what ratio can still be
considered acceptable. 15%, 20%, or more?

--------------

2.2 Regular Occurrence of Extraordinary Circumstances
    [hard-detectable-evidence vulnerability]

This can be a real danger. Regular occurrence can be quite easily
overcome by tasting registrars running a higher number of properly
configured phantom registrars on background. For example, SnapNames
company runs at least 111 phantom registrars. Assume the first phantom
registrar tastes, e.g. 80% - 100% of all net new domains during one
month. This is no doubt a suspect extraordinary circumstance. However,
if accepted by Registry for whatever reason, the next phantom registrar
will do the same in the next 5-day period, and so on. Provided every new
5-day period is 'served' (abused) by different phantom registrar, the
regularity appears in 111 x 5 days. That is, the first phantom registrar
will come into play again until after 555 days, which is almost 1.3
years. During all that time the abuse is fluently and silently running
for the given company, as there is formally NO breach of this provision.

Currently, the SnapNames phantom registrars are almost all identifiable
by the same IP address or IP address block. However, if reconfigured and
redistributed, the situation might get much harder to recognize.

To review the list of current phantom registrars see

http://www.dotandco.net/ressources/icann_registrars/websites/byip.en#ip_
69_64_145_229


* * * * * * * * * * * *

3. The GNSO Oversight
   [lack-of-criteria, slow-reaction, conflict-of-interests
vulnerability]

This can be a critical point of this proposal. The possible weak points
are

- Lack of criteria upon which the situation will be effectively
  monitored and evaluated

- Flagging interest in dealing with the oversight on regular basis

- Downplaying of possible problems by interested influential parties
  (Registries and Registrars)

- Slow reaction to act in case of problems

- Possible personal resources and budget requirements to keep
  the oversight functioning

- Missing feedback and public participation specification
  on the monitoring


* * * * * * * * * * * *


Dominik