<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [registrars] Registration and renewal price in .com registry agreement
- To: "'Elana Broitman'" <ebroitman@xxxxxxxxxxxx>, Paul Stahura <stahura@xxxxxxxx>, elliot noss <enoss@xxxxxxxxxx>, Bruce Tonkin <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>
- Subject: RE: [registrars] Registration and renewal price in .com registry agreement
- From: Paul Stahura <stahura@xxxxxxxx>
- Date: Wed, 15 Oct 2003 11:33:44 -0700
- Cc: registrars@xxxxxxxx
- Sender: owner-registrars@xxxxxxxxxxxxxx
If ICANN truly believes that it does not scale, then
it is no skin off their back to commit to not scaling
(increasing our fees). If they do not commit to a cap,
then at least we know they really don't believe it can't scale.
I think we should put ourselves and ICANN on notice that
we will not pay more next time, and if asked too,
the chips will fall where they may. This will give us
and ICANN more incentive (and a year) to actually find
these other sources. Otherwise, everyone will lay back,
not put as big an effort into it, because they'll think
if worse comes to worse, we'll just increase the fee
to registrars again. It will be worse for us, ICANN, and
pretty much everyone else, if it comes as a surprise when
the registrars don't pay.
Without committing to each other (to ICANN and among
ourselves) to a cap at today's level,
I'm not sure there is sufficient incentive in order to
not exceed the cap. Its sort of a self-fulfilling thing.
No cap commitment now, then that would likely
mean, IMO, that we will be paying even more next year.
With a cap commitment now, I believe then we won't,
yet ICANN will get more funding (from other sources).
I would like the letter to state that the registrars who sign,
now give notice and contractually commit that we
will reject an increase next year. If NSI could be contractually bound
to approve, why can we be contractually bound to disaprove?
Paul
-----Original Message-----
From: Elana Broitman [mailto:ebroitman@xxxxxxxxxxxx]
Sent: Wednesday, October 15, 2003 11:06 AM
To: Paul Stahura; elliot noss; Bruce Tonkin
Cc: registrars@xxxxxxxx
Subject: RE: [registrars] Registration and renewal price in .com registry
agreement
Paul - would you want to approve, based on a stronger statement than we'd
sent around?
Again, it is:
Elana Broitman
Register.com
575 Eighth Avenue
New York, NY 10018
Phone (212) 798-9215
Fax (212) 629-9309
ebroitman@xxxxxxxxxxxx
-----Original Message-----
From: Paul Stahura [mailto:stahura@xxxxxxxx]
Sent: Wednesday, October 15, 2003 1:57 PM
To: 'elliot noss'; Bruce Tonkin
Cc: registrars@xxxxxxxx
Subject: RE: [registrars] Registration and renewal price in .com
registry agreement
eNom feels that the current method of funding ICANN does not scale because
in either case (registry pays directly or registrars pay directly)
the burden falls to registrars and with our competitive situation,
it is difficult to pass the fee on to registrants so it therefore comes out
of our
other sources of income. In effect then, ICANN is mostly/partially funded
by hosting
and other income (and in many cases, shareholders) of registrars, not by
registrants.
What needs to be done is for ICANN to find other sources of income.
TLD auctions, wildcard, governments, whois... there are many.
But none will be easy. After all, who really truly *wants* to pay?
Registrars have an incentive to help ICANN in this search, but
ICANN needs to know it *must* do its share of searching for these sources
too,
and that it cannot rely on registrars any longer.
Otherwise, as Bruce points out, out of desperation,
the funding sources will collapse (to pretty much one direct funder,
Verisign), not expand.
Funding ICANN must be spread across more and more and more direct payers
(and more indirect, too) besides registrars
(yes, there is some ICANN funding from a few other entities, but as we
all know registrars are the current source of the vast majority of the
funding).
More sources makes ICANN more stable, which is what we all want.
I would like a commitment from ICANN beyond a non-committal statement that
the current method
does not scale, something more like "not only does it not scale, but it
won't be scaled"
In other words, that the burden from registrars to ICANN will be capped at
the current level.
Elliot, about your irony statement: I guess you are saying it is ironic
that some registrars
are complaining about funding ICANN when at the same time litigation compels
ICANN to spend money.
Many registrars feel strongly that when it comes to WLS, that ICANN did not
hold up
their end of the deal (our contracts), and at the same time also feel
strongly that registrars
are footing too much of the ICANN budget bill.
I for one, would rather not bring litigation against anyone, let alone
ICANN.
So, I see what you are saying but I'd like to point out that:
1) ICANN decided on the budget (and the dramatic increase in our fee) before
the litigation.
2) Any registrars who do not want a fee increase would complain regardless
of any litigation costs
3) I do not think there is one registrar who is not complaining about a 50%
increase in our fees,
so therefore, yes, any registrar involved in the litigation would, be
definition, also be complaining.
4) The litigation will be a very small cost in comparison to the rest of
ICANN's *next* budget.
5) I don't think any registrars who are involved in the litigation (and
probably many who are not)
want ICANN to spend money on it: ICANN could not fight it and save money
:>)
I would be remiss if I also didn't note the irony that Verisign, who
proposed WLS,
is not part of the litigation (has no costs there) and also will not have
their ICANN fees increased.
That's the real irony.
Paul
-----Original Message-----
From: elliot noss [mailto:enoss@xxxxxxxxxx]
Sent: Wednesday, October 15, 2003 7:39 AM
To: Bruce Tonkin
Cc: registrars@xxxxxxxx
Subject: Re: [registrars] Registration and renewal price in .com registry
agreement
Bruce has eloquently described exactly how we feel. So just to be
clear, Tucows will also agree to be invoiced directly.
I would be remiss if I also didn't note the irony of registrars both
engaged in litigation with ICANN and complaining about budget increases.
Regards
On Tuesday, October 14, 2003, at 11:00 PM, Bruce Tonkin wrote:
> Hello All,
>
> For information. Here is the relevant clause from the .com registry
> agreement.
> From:
> http://www.icann.org/tlds/agreements/verisign/registry-agmt-com-
> 25may01.
> htm
>
>
> "E. Adjustments to Price. The maximum pricing for initial and renewal
> registrations set forth in Appendix G shall be adjusted at the
> beginning
> of each calendar quarter by adding, to the amount specified in that
> Appendix (after adjustment according to Section 22(a)) as the
> applicable
> annual charge for initial or renewal registration of a domain name, an
> amount calculated according to the following three sentences. For
> calendar quarters in which the variable fee is collected at the
> registrar level, the amount shall be US$0.00. For the first two
> calendar
> quarters during the Term of this Agreement in which the variable fee is
> collected at the registry level, the amount shall be four times the
> per-name variable accreditation fee charged to registrars for the
> quarter beginning six months earlier. For subsequent calendar quarters,
> the amount shall be four times the quarterly Variable Registry-Level
> Fee
> reflected in the invoice to Registry Operator for such a fee for the
> quarter beginning six months earlier divided by the number of
> Registered
> Names that the invoice shows was used to calculate that quarterly
> Variable Registry-Level Fee. The adjustments permitted by this
> Subsection 7(E) shall only apply for periods of time as to which the
> Registry Operator does not have in effect a provision in its
> Registry-Registrar Agreement permitting it to require ICANN-Accredited
> Registrars to pay to Registry Operator a portion of Registry Operator's
> payments of variable registry-level fees to ICANN."
>
> Thus the ability for the Verisign registry to increase the per domain
> name price to collect the increase from registrars is effectively
> hard-coded into the contract.
>
> In a pure market, an operator may decide not to pass on the increase to
> their customers. But who will decide not to offer .com names because
> the price increases by say less than $1.
>
> The issue may be harder for an operator such as .name, where a price
> increase may be enough for a registrar to choose not to offer the
> service.
>
> Contrast this with our situation,. Many of us absorb ICANN fee
> increases, because we are in a very competitive market, and our
> customers can choose from over 100 other registrars, and probably
> thousands of domain name resellers. Some of these companies sell
> domains at below their market value, on the basis that they will pick
> up
> business through value added products.
>
> Anyway I predict the following result if registrars decline to pay
> ICANN
> directly:
> - Verisign will increase its leverage over ICANN (as they will pay a
> larger portion of ICANN's fee) - they could for example delay payment
> which would impact ICANN ability to pay their staff, which would impact
> the ability of ICANN to regulate services such as WLS and Sitefinder.
> - once Verisign eventually pays ICANN, they will subsequently increase
> our fees
> - other registry operators may have a harder decision based on their
> market position - although most wouldn't be able to afford to pay ICANN
> without passing on the fee
>
> What we gain is a delay in making a payment (improves short term cash
> flow), what we lose is long term leverage.
>
> Now we can always ask the registry operators what they intend to do,
> although such discussions may give rise to anti-trust implications
> amongst the registry operators (e.g discussing possible price changes).
>
> Anyway for the reasons above, given that the budget and contractual
> structure for meeting the budget is set, Melbourne IT will agree to be
> invoiced directly by ICANN. We feel that giving more leverage to
> registries at this time would be a dangerous step.
>
> Regards,
> Bruce
>
>
>
>
>
>
>
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|