[council] Issues Report re Abuse Policies -- request for clarification from Counsel

Wed Nov 19 23:41:10 UTC 2008

Thanks Liz.  I appreciate the attempt to clarify, but I am still not clear
about what is in and out of potential scope.  With both the UDRP
(cybersquatting) and fast flux exploits, nobody would care whether the
domain in question was registered, if it were not used in a criminal and/or
infringing (aka abusive) manner.  The ICANN Board (wrt the UDRP) and ICANN
Staff and GNSO Council (wrt fast flux exploits) have found that abusive
registrations are within scope of GNSO policy development, and there is
further support for that in the mission statement.  

I don't understand the distinction that Staff seems to be trying to make
now, nor how it impacts the Council's decision-making on next steps to
address this Issues Report.  If any Councilors or Staff have ideas, I'd love
to hear them.  My thought is we should launch a PDP to determine whether
gTLD registries and registrars should have a consistent set of minimum
standards and processes to deal with abusive registrations.  Assuming so,
what are those standards and processes?  The Afilias funnel request provides
one possible way, several other ideas have been floated in the Fast Flux WG,
in ICM's .xxx proposal re "Rapid Takedown", and elsewhere.

Policy development is imperative to address the current volume of abusive
registrations, and especially with newTLDs coming online next year, and with
the expected growth in use of IDNs.  Private and public law enforcement
entities are already overstressed to deal with the volume and intensity of
abusive registration problems, and the growth of the domain space will only
increase that stress.  Businesses, individuals and non-profit entities
cannot be expected to continue footing the bill for so-called 'defensive
registrations' in effort to protect their brands, and instead ICANN must
develop post-registration mechanisms to effectively deal with abusive
registrations.  A solid set of minimum standards and processes, required of
all accredited registrars and gTLD registries, would be a good start.

Thanks,

Mike

  _____  

From: owner-council at gnso.icann.org [mailto:owner-council at gnso.icann.org] On
Behalf Of Liz Gasster
Sent: Wednesday, November 19, 2008 2:40 PM
To: icann at rodenbaugh.com; 'GNSO Council'
Subject: RE: [council] Issues Report re Abuse Policies -- request for
clarification from Counsel

Mike and all,

Thank you for your inquiry.  The sentences you asked about in the
registration abuse issues report should be read in the context of the
preceding sentences in that paragraph, which read as follows:

"Note, section 4.2.3 of the Registrar Accreditation Agreement between ICANN
and accredited registrars provides for the establishment of new and revised
consensus policies concerning the registration of domain names, including
abuse in the registration of names, but policies involving the use of a
domain name (unrelated to its registration) are outside the scope of
policies that ICANN could enforce on registries and/or registrars."

For your reference, RAA section 4.2.3 provides that ICANN may obligate
registrars to implement new policies concerning the "resolution of disputes
concerning the registration of Registered Names (as opposed to the use of
such domain names), including where the policies take into account use of
the domain names ..."

<http://www.icann.org/en/registrars/ra-agreement-17may01.htm#4.2.3>

In the case of fast flux we said that some aspects of fast flux hosting are
within scope because fast flux involves the rapid update of nameserver
registration records in gTLDs.  Rapid update of nameserver registration
records specifically involves the registration of names, which can be
distinguished from a case where a name, once registered, resolves to a site
that contains infringing or otherwise abusive content.  While ICANN could
change policy with regard to updates of nameserver registration records,
ICANN might not be able to impose any new obligations on registrars
concerning pure content/use disputes.

Please let me know if you have any further questions.

Thanks, Liz

From: owner-council at gnso.icann.org [mailto:owner-council at gnso.icann.org] On
Behalf Of Mike Rodenbaugh
Sent: Wednesday, November 05, 2008 6:51 AM
To: icann at rodenbaugh.com; 'GNSO Council'
Subject: RE: [council] Issues Report re Abuse Policies -- request for
clarification from Counsel

Sorry, tired today, re-sending to clarify that this is a request for
clarification from ICANN Counsel, not the GNSO Council.  Thanks.

  _____  

From: owner-council at gnso.icann.org [mailto:owner-council at gnso.icann.org] On
Behalf Of Mike Rodenbaugh
Sent: Wednesday, November 05, 2008 6:36 AM
To: 'GNSO Council'
Subject: [council] Issues Report re Abuse Policies -- request for
clarification from Council

Hi,

I refer to Sec. 7.1 of the Report, which ends with these sentences:

The use of domain names may be taken into account when establishing or
changing registration policies. Thus, potential changes to existing
contractual provisions related to abuse in the registration of names would
be within scope of GNSO policy making. Consideration of new policies related
to the use of a domain name unrelated to its registration would not be
within scope.

Could ICANN Counsel please clarify this language?  Specifically, what could
be "use of a domain name unrelated to its registration"?  If this means "any
use of a domain name after it is registered", then how is that opinion
consistent with prior enactment of the UDRP, and Counsel's opinion in the
Issues Report re Fast Flux Hosting (Mar. 31, 2008, p. 14):

General Counsel's opinion is that some aspects relating to the subject of
fast flux hosting are within scope of the ICANN policy process and within
the scope of the GNSO. As fast flux 

hosting activities concern gTLDs, the issue is within the scope of the GNSO
to address.

This clarification and/or further analysis might be very helpful for the
Council in considering the latest Issues Report in the coming weeks, before
our next meeting.

Thanks,

Mike R.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/council/attachments/20081119/09aff994/attachment.html>