Date: Thu, 28 Mar 2024 09:34:34 +0000 (UTC) Message-ID: <1386394935.14286.1711618474397@community1.lax.icann.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_14285_914556452.1711618474397" ------=_Part_14285_914556452.1711618474397 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
STATUS OF THIS DOCUMENT: Final text, being vote=
d on by the ALAC
COMMENTS DUE BY: 7th September 2008 Mi=
dnight UTC
Thank you for the opportunity to comment on the recent proposed amendmen= ts to the Registrar Accreditation Agreement.
This statement comprises four parts: =E2=80=9CBackground,=E2=80=9D =E2= =80=9CCurrent Amendments and Issues,=E2=80=9D =E2=80=9CRemaining proposals = from =E2=80=98Section F,=E2=80=99 =E2=80=9D and =E2=80=9CConclusion.=E2=80= =9D
Part I =E2=80=93 Background
Late last fall, a working group of the following participants was create= d:
RJ Glass
Vittorio Bertola
Michele Neylon
Hugh Dierker
Debbie Garside
John Levine
Jacqueline Morris
Nirmol Agarwal
Seth Reiss
Derek Smythe
Jeff Williams
Danny Younger
This collection of individuals set forth policy recommendations for the = RAA, which were then endorsed by the At-Large Advisory Committee and sent t= o the Board of Directors of ICANN as an Advisory on 8th August 2008. That s= tatement may be found at: http://www.atlarge.icann.org/en/correspondence/community-view= s-raa-negotiation.htm.
However, of 27 separate recommendations tendered, the ICANN Staff select= ed one =E2=80=93 specifically, the inclusion of a standardized description = of registrant rights within the RAA.
Those in that working group and other members of the user community beli= eve the proposed amendments to the RAA do not reflect the most important as= pects of that group=E2=80=99s work. Further, throughout the agreement revie= w process, public comments have been tendered in good faith that were later= put aside by the ICANN Staff. Many of them, we believe, were specific impl= ementable recommendations from the general public. These also have been put= aside. The resulting set of amendments, therefore, is weak overall.
Part II =E2=80=93 Current Amendments and Issues
In reference to item 2 b, =E2=80=9CRequiring registrars to include on th= eir websites a link to a =E2=80=98Registrant Rights and Responsibilities=E2= =80=99 document to be created in consultation with the ICANN community,=E2= =80=9D we would like to make clear the ALAC has begun work on this document= and hopes to circulate it to the community in September 2008.
We have the following concerns and comments about the other amendments:<= /p>
Generally speaking, Inin the =E2=80=9CEnforcement Tools=E2=80=9D section= , we believe the language does not go far enough to create deterrence, nor = is it specific enough about the terms of graduated sanctions against non-co= mpliant registrars.
Specifically, in 1 a: We recommend deleting =E2=80=9Cat least.=E2=80=9D = 15 days is more than enough advance notice of an audit.
In 1 b: What are the proposed graduated monetary sanctions, in US dollar= s, and to what violations do they correspond?
In reference to 1c: =E2=80=9CGroup Liability =E2=80=93 Preventing =E2=80= =98serial misconduct=E2=80=99 by registrars when another affiliated (by com= mon control) registrar's RAA is terminated,=E2=80=9D we ask =E2=80=93 not j= ust for this specific item and event but for the spirit of the RAA as a who= le =E2=80=93 why should ICANN and the user community tolerate =E2=80=9Cseri= al misconduct=E2=80=9D at all? A single willful fundamental and material co= ntract breach should be sufficient to warrant a loss of accreditation. ICAN= N, rather than the registrars, should be responsible for enforcement and di= sclosure.
Further, without endorsing any particular dispute resolution policy, tra=
nsparency about their effects is useful. Concrete information-forcing mecha=
nisms, e.g., requiring prominent notification of deviations from a standard=
set of contract terms, is preferable, since market competition only works =
when consumers know they are making a choice and understand the
terms of the choice. Within the context of compliance enforcement in gener=
al, ICANN should require public display and disclosure of all registrar off=
icers and directors, particularly in the event a registrar=E2=80=99s accred=
itation is terminated.
In 2c: We recommend removing the clause, =E2=80=9Cor alternatively, give= prominent notification that such data will not be escrowed,=E2=80=9D becau= se we cannot foresee a circumstance in which not escrowing would be desirab= le.
In 3c: Concern grows in the user community about compliance among ICANN-= accredited registrars. It is one thing to display a seal or logo, and quite= another to be fully in compliance with its requirements. Significant numbe= rs of users have come forward to question whether, in fact, those registrar= s who claim compliance, fully are. It is an intrinsic flaw in =E2=80=9Cseal= =E2=80=9D programs that they require policing to be effective. We would lik= e to see evidence that there is, in fact, ongoing review of compliance amon= g ICANN registrars that display such seals, which are an enticement to the = general public. Those found not to be fully should lose the right to displa= y the seal while compliance investigation is ongoing.
Other general issues: Since the consultation period, several members of = the user community (and the business constituency in the ICANN community) h= ave raised concern about domain name warehousing. At the moment there appea= rs to be no contractual or compliance language that prevents registrars fro= m =E2=80=9Cwarehousing=E2=80=9D expired domain names. We believe this creat= es an unfair situation for members of the public who might wish to own a pa= rticular domain name. A number of ICANN-accredited registrars have admitted= to engaging in this practice and the user community has made clear its obj= ections.
In addition, the user community and the ICANN community has spent time a= nd resources recently discussing contractual violations such as front-runni= ng. Where are the provisions in the RAA to deal with this problem?
When registrars pay for multiple-year registrations and the registrar en= ters only a single year into the WHOIS record, what RAA provisions will ens= ure the registrant is protected should the registrar go under?
When a registrar reacts to a customer charge-back by changing the WHOIS = record for the registrant's other registrations, what provisions in the RAA= will make the registrant whole?
Part III =E2=80=93 Remaining proposals from =E2=80=9CSection F= =E2=80=9D
As noted in the =E2=80=9CBackground=E2=80=9D section at the beginning of= this statement, in response to the ALAC=E2=80=99s submission during the in= itial consultation period, ICANN staff, in its summary of comments, grouped= many of ALAC=E2=80=99s proposed additions to the agreement in Section F. S= everal members of the user community note that the Staff Analysis of Sectio= n F of the Synthesis of Public Comments (Analy= sis for ALAC of Section F) reads as if it were written in direct consul= tation with the registrar community. However, we do recognize and appreciat= e Tim Cole=E2=80=99s clarification of some of these issues in briefings to = the ALAC in Los Angeles and by phone in August 2008.
In addition, certain events have made some proposals in Section F moot. = However, we believe the following suggested amendments remain valid candida= tes for consideration (some with slight wording modifications):
=E2=80=A2 While customers should be able to select a registrar based on =
its willingness to be responsive to its customer=E2=80=99s desires, ICANN s=
hould seek to limit disclaimers by registrars that are not in compliance wi=
th all terms of the agreement. This is obviously critical for ICANN-accredi=
ted registrars.
=E2=80=A2 ICANN should require standardized Acceptable Use Policy in regis=
tration agreements to address criminal fraud, when this directly affects th=
e operational stability, reliability, security and global interoperability =
of the Internet.
=E2=80=A2 Enforce and make public the results of dispute mechanisms in pla=
ce that obligate registrars to facilitate enforcement of abusive registrati=
on policies, such as the UDRP.
=E2=80=A2 Registrars should be required to offer DNSSEC.
Part IV =E2=80=93 Conclusion
Thus far we have received the proposed revisions to the RAA but we have = yet to hear the results of the comprehensive review of the registrar accred= itation process. In a late August posting, the spam mitigation firm Knujon = pointed to the nefarious activities of a single registrar associated with i= llicit pharmaceuticals that has sponsored 48 phantom accreditations. Extend= ing accreditations to shell companies formed for the express purpose of gam= ing the system must stop. These phantom registrars are currently being used= to game the aftermarket, but as we move into the new gTLD cycle, they will= next be used to actively game the new gTLD landrush periods.
As a community, we are aware of accredited registrars in North America w= ith officers that have been convicted of mail fraud, that continue to be as= sociated with the deceptive marketing practices employed by the Domain Regi= stry of America. We do not consider this an acceptable situation. Accredita= tion processes must be reviewed, and that review must be released for publi= c scrutiny.
We are aware of registrars that now stand as defendants in courts of law= accused of cybersquatting, yet ICANN lacks the will to suspend their accre= ditations. Where is the commitment to protection of the public interest? Wh= ere is the respect for the community view? And when the next RegisterFly in= cident occurs, what provision in the RAA will give remedy to the registrant= ?