<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [council] Request for Issues Report re Registration Abuse Policies
- To: icann@xxxxxxxxxxxxxx, Council GNSO <council@xxxxxxxxxxxxxx>
- Subject: Re: [council] Request for Issues Report re Registration Abuse Policies
- From: Greg Ruth <greg_ruth@xxxxxxxxx>
- Date: Thu, 28 Aug 2008 07:45:15 -0700 (PDT)
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=owZC4maKj6j49Mq1ULyD6esLNTEN7XTKOpgb7DDeVi2pN03NHyNMUBitnnXRiNKIeV/RZmqK2sYAmLBeQfugUaQftvusoGZUBKP1nQ1p26xVHSGFDYfUplLl8/zrfBHVuIO0qW2C1oz/R17vDwlUaK+PWmPt3Z0iuDgwdy+BNZA=;
- List-id: council@xxxxxxxxxxxxxx
- Sender: owner-council@xxxxxxxxxxxxxx
I would like to second Mike's motion.
Greg
----- Original Message ----
From: Mike Rodenbaugh <icann@xxxxxxxxxxxxxx>
To: Council GNSO <council@xxxxxxxxxxxxxx>
Sent: Thursday, August 28, 2008 1:36:58 AM
Subject: [council] Request for Issues Report re Registration Abuse Policies
Hello,
A signficant discrepancy in registry contracts exists, with respect to language
intended to allow registries to take action against abuse. The recent Afilias
funnel request highlights the issue, as has a related discussion in the Fast
Flux WG. The BC proposes a Council resolution to request Staff to lay out the
facts and potential options around this issue, for further community
discussion.
I hope we can discuss this and have a vote at our next meeting on Sept. 4th.
Thanks,
Mike Rodenbaugh
Councilor, Business Constituency
Whereas:
1. ICANNʼs mission is to ensure the security and stability of
the DNS, and to develop policy reasonably related to that mission.
2. Various forms of DNS abuse, in isolation and/or in the
aggregate, cause a less secure and stable DNS.
3. Some of ICANNʼs gTLD registry agreements and appended
registry-registrar agreements contain a provision such as Section 3.6.5 of the
.info Registry Agreement, Appendix 8
(http://www.icann.org/en/tlds/agreements/info/appendix-08-08dec06.htm):
3.6.5. [Registrars] acknowledge and agree that Afilias reserves the right
to deny,
cancel or transfer any registration or transaction, or place any
domain name(s) on registry lock, hold or similar status, that it deems
necessary, in its discretion; (1) to protect the integrity and
stability of the registry; (2) to comply with any applicable laws,
government rules or requirements, requests of law enforcement, or any
dispute resolution process; (3) to avoid any liability, civil or
criminal, on the part of Afilias, as well as its affiliates,
subsidiaries, officers, directors, and employees; (4) per the terms of
the registration agreement or (5) to correct mistakes made by Afilias
or any Registrar in connection with a domain name registration.
Afilias also reserves the right to place upon registry lock, hold or
similar status a domain name during resolution of a dispute.
4. Afilias, the dotInfo Registry Operator, per its recent
RSEP request, has sought to clarify and implement its specific abusive
registration policy with respect to this provision. This request has been
approved by ICANN,
http://www.icann.org/en/registries/rsep/afilias-to-icann-06aug08.pdf.
5. Some of ICANNʼs gTLD registry agreements, notably the
Verisign contracts for .com and .net, have no such provision. Other gTLD
registry agreements do contain such provision, but the registry operators have
not developed or have inconsistently developed abusive registration policies.
The GNSO Council resolves to request an Issues Report from ICANN Staff with
respect to the following:
1. To identify and describe the various provisions in existing and
previous gTLD registry and registry-registrar agreements which relate to
contracting partiesʼ ability to take action in response to abuse.
2. To identify and describe various provisions in a representative
sampling of gTLD registration agreements which relate to contracting partiesʼ
and/or registrants rights and obligations with respect to abuse.
3. To identify and describe any previous discussion in ICANN fora which
substantively pertains to provisions of this nature in any of these agreements.
4. To identify and describe potential options for further Council
consideration, relating to consistency and propriety of provisions of this
nature in all of these agreements.
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|