ICANN/GNSO GNSO Email List Archives

[registrars]


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

RE: [registrars] PLEASE confirm your support of this Statement

  • To: bhavin.t@xxxxxxxxxxxxxx
  • Subject: RE: [registrars] PLEASE confirm your support of this Statement
  • From: Tim Ruiz <tim@xxxxxxxxxxx>
  • Date: Tue, 22 Nov 2005 20:58:07 -0700
  • Cc: jnevett@xxxxxxxxxxxxxxxxxxxx, registrars@xxxxxxxxxxxxxx
  • Sender: owner-registrars@xxxxxxxxxxxxxx

Go Daddy, Wild West, and Blue Razor support the statement.

Tim Ruiz
The Go Daddy Group, Inc.


> -------- Original Message --------
> Subject: [registrars] PLEASE confirm your support of this Statement
> From: "Bhavin Turakhia" <bhavin.t@xxxxxxxxxxxxxx>
> Date: Tue, November 22, 2005 8:53 pm
> To: "'Nevett, Jonathon'" <jnevett@xxxxxxxxxxxxxxxxxxxx>,       
> <registrars@xxxxxxxxxxxxxx>
> 
> 
>    Hi everyone.
> 
>    Just to be clear, apart from
>    posting this to the comments
>    yourself, please also send a
>    confirmation to Jon or myself
>    that you support this
>    statement. Since I will be
>    shortly sending this statement
>    to the ICANN Board as an
>    official statement from the
>    constituency
> 
>    bhavin
>      _________________________
>    From:
>    owner-registrars@xxxxxxxxxxxxx
>    g
>    [mailto:owner-registrars@gnso.
>    icann.org] On Behalf Of
>    Nevett, Jonathon
>    Sent: Tuesday, November 22,
>    2005 7:30 PM
>    To: registrars@xxxxxxxxxxxxxx
>    Subject: [registrars]
>    Registrars Statement on .com
>    agreement
>    Registrar Colleagues:
> 
>    The Registrar Constituency
>    .com Working Group set up by
>    Bhavin has drafted the
>    following statement.  Please
>    feel free to sign on to the
>    statement and to post it to
>    the ICANN website -- to post
>    comments, please send an
>    e-mail to:
>    settlement-comments@xxxxxxxxx.
> 
>    Thanks.
> 
>    Jon
> 
>    We, the undersigned
>    registrars, recommend against
>    ICANN signing the
>    proposed .com Registry
>    Agreement.   The following
>    reflects those issues
>    that are of foremost concern
>    to registrars:
> 
>    1.    New Registry Services
> 
>    The proposed .com contract
>    locks ICANN and VeriSign in
>    for three years
>    on a version of the consensus
>    policy covering the standards
>    and process
>    for consideration of new
>    registry services.  The new
>    registry services
>    consensus policy process that
>    recently was approved by the
>    ICANN board
>    is untested, and it is likely
>    that the ICANN community will
>    need to
>    refine and improve it after it
>    is implemented.  A three year
>    lock will
>    unnecessarily handcuff ICANN
>    and the ICANN community.
> 
>    We recommend the deletion of
>    Sections 3.1(b)(v)(B) and
>    3.1(b)(v)(C), and
>    allowing the existing ICANN
>    policy development and
>    refinement process to
>    be used during the term of the
>    agreement.
> 
>    2.    Registry Agreement
>    Renewal
> 
>    According to its own Bylaws
>    and the Memorandum of
>    Understanding between
>    ICANN and the United States
>    Department of Commerce, one of
>    ICANN's core
>    missions is to promote
>    competition.  We understand
>    that the current .com
>    contract contains a
>    "presumptive renewal"
>    provision, which by its nature
>    hinders competition.  The
>    proposed .com contract,
>    however, goes much
>    farther than the existing
>    contract by strengthening the
>    presumptive
>    renewal and termination
>    provisions on behalf of
>    VeriSign, thereby making
>    it virtually impossible for
>    VeriSign to lose the .com
>    registry and
>    impossible to reap the
>    benefits of competition.
>    VeriSign should be
>    appointed as the administrator
>    of the .com registry, not its
>    owner.
> 
>    We recommend reverting from
>    Section 4.2 of the proposed
>    .com agreement
>    to the renewal terms of
>    Section 25 of the current .com
>    agreement, which
>    requires a six month review of
>    a "Renewal Proposal" provided
>    by VeriSign
>    and only under terms that are
>    in "substantial conformity
>    with the terms
>    of registry agreements between
>    ICANN and operators of other
>    open TLDs.
>    . ."   ICANN also should
>    strengthen the termination
>    provisions currently
>    contained in Section 6.1 of
>    the proposed agreement by
>    using the relevant
>    text from Sections 16(B-E) of
>    the current agreement.
> 
>    3.    Registry Fees
> 
>    The proposed .com contract
>    would permit VeriSign to
>    unilaterally raise
>    registration fees by 7% per
>    year.  The existing .com
>    contract and all
>    gTLD registry agreements
>    (other than the .net agreement
>    with VeriSign,
>    which was entered into without
>    community input in violation
>    of ICANN's
>    Bylaws) require the registries
>    to cost-justify any price
>    increases.  In
>    an industry where the
>    economics suggest that fees
>    should be going down
>    when there is competition, it
>    is particularly troublesome
>    and
>    anti-competitive to grant a
>    monopolist or a single source
>    provider the
>    unilateral right to increase
>    costs without justification.
>    Unfortunately, these fee
>    increases would result in cost
>    increases to
>    individual registrants.  We
>    note that in the recent
>    competitive process
>    for .net, VeriSign
>    significantly lowered its
>    registry fees.  There is no
>    reason for unilateral cost
>    increases for the larger .com
>    registry.
> 
>    We recommend that the Board
>    delete the current text of
>    Section
>    7.3(d)(ii) and replace it with
>    Section 22(A) of the current
>    .com
>    agreement requiring VeriSign
>    to justify and ICANN to
>    approve any
>    proposed fee increase.  If
>    there is a dispute between
>    ICANN and VeriSign
>    over a cost increase, ICANN
>    should have the right to seek
>    competitive
>    price proposals from other
>    registry operators to ensure
>    that the ICANN
>    community receives the
>    benefits of competition.
> 
>    4.    New ICANN Fees
> 
>    ICANN and VeriSign propose a
>    new ICANN fee that would be
>    assessed on
>    VeriSign and passed on to the
>    registrars.  This fee would
>    result in
>    excess of approximately $150
>    million dollars to ICANN, and
>    would be an
>    end run around the existing
>    ICANN budget approval
>    process.  As proposed,
>    ICANN staff has removed an
>    important check on the ICANN
>    budget process.
>    All ICANN fees that impact
>    registrants should be subject
>    to the ICANN
>    budget approval process and
>    should not only be the subject
>    of
>    negotiations between VeriSign
>    and ICANN.
> 
>    In addition to the changes
>    suggested in number 3 above,
>    we recommend the
>    removal of Sections 7.3(g-h)
>    in the proposed contract.  Any
>    transaction
>    fees that ICANN needs to
>    collect from registrars (and
>    hence registrants)
>    should be assessed through the
>    current transaction fees
>    charged by ICANN
>    to registrars and be subject
>    to the existing budget
>    approval process.
> 
>    While we understand the desire
>    to finalize the litigation, it
>    should not
>    be done so without a
>    sufficient review process nor
>    at the expense of
>    major tenets of ICANN's
>    mission.  In its current form,
>    it is a bad
>    settlement for ICANN, the
>    ICANN community, and the
>    public-at-large.  We,
>    therefore, urge the ICANN
>    Board to take advantage of the
>    six month
>    review of a "Renewal Proposal"
>    contemplated in the existing
>    .com
>    agreement, which doesn't
>    expire until November 2007.
>    The Board should
>    use this time to review the
>    complicated contracts in their
>    entirety,
>    have a public comment period
>    commensurate with the
>    importance of the
>    issue, and make the changes
>    necessary to improve the
>    agreement.




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