[LAC-Discuss] [Fwd: [APAC-Discuss] The ISOC-AU ICANN_DomainTasting2.pdf]
Carlton Samuels
carlton.samuels at uwimona.edu.jm
Tue May 20 13:02:43 EDT 2008
I have!
CAS
-----Original Message-----
From: lac-discuss-bounces at atlarge-lists.icann.org
[mailto:lac-discuss-bounces at atlarge-lists.icann.org] On Behalf Of Jacqueline
A. Morris
Sent: Tuesday, May 20, 2008 07:13 AM
To: ttcs at yahoogroups.com; LAC Discuss
Subject: [LAC-Discuss] [Fwd: [APAC-Discuss] The ISOC-AU
ICANN_DomainTasting2.pdf]
FYI
Cheryl Langdon-Orr wrote:
>
> Please find attached the very simple support in principal of the
> Boards voting for the Domain Tasting Motion that the ISOC-AU Board has
> approved to be submitted.
>
> Is it possible for the RALO to also put on (and any other ALS of
> course) a similarly simple opinion piece that says we support anything
> that stops Domain Tasting and if this does it fine but it needs to be
> monitored so that actual effects are measured and if insufficient then
> MORE needs to be done. The GA list has a rather interesting analysis
> of some of the aspects of this issue and some of you / the Executive
> of the RALO may find some useful material there as well. I've attached
> the original message to the GA list here for ease of access. The
> closing date for any comments is 21 May but surely someone could do
> something in time.
>
> CLO
>
>
> ----------------------------------------------------------------------
> --
>
> Subject:
> [ga] GA_ISSUE-001: Domain Tasting | 10% AGP Cap Proposal - Analysis
> From:
> "Dominik Filipp" <dominik.filipp at dsoft.sk>
> Date:
> Fri, 16 May 2008 04:55:36 +1000
> To:
> <ga at gnso.icann.org>
>
> To:
> <ga at gnso.icann.org>
>
>
> 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/glob
> al
> /)
>
> 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#i
> p_
> 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
>
>
> ----------------------------------------------------------------------
> --
>
> _______________________________________________
> APAC-Discuss mailing list
> APAC-Discuss at atlarge-lists.icann.org
> http://atlarge-lists.icann.org/mailman/listinfo/apac-discuss_atlarge-l
> ists.icann.org
>
> Homepage for the region: http://www.apralo.org
-------- Original Message --------
Subject: [APAC-Discuss] The ISOC-AU ICANN_DomainTasting2.pdf
Date: Tue, 20 May 2008 17:44:08 +1000
From: Cheryl Langdon-Orr <cheryl at hovtek.com.au>
Reply-To: cheryl at hovtek.com.au
Organization: Hovtek Pty Limited
To: <apac-discuss at atlarge-lists.icann.org>
Please find attached the very simple support in principal of the Boards
voting for the Domain Tasting Motion that the ISOC-AU Board has approved to
be submitted.
Is it possible for the RALO to also put on (and any other ALS of course) a
similarly simple opinion piece that says we support anything that stops
Domain Tasting and if this does it fine but it needs to be monitored so that
actual effects are measured and if insufficient then MORE needs to be done.
The GA list has a rather interesting analysis of some of the aspects of this
issue and some of you / the Executive of the RALO may find some useful
material there as well. I've attached the original message to the GA list
here for ease of access. The closing date for any comments is 21 May but
surely someone could do something in time.
CLO
More information about the lac-discuss-en
mailing list