ICANN/DNSO
DNSO Mailling lists archives

[ga]


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

RE: [ga] FYI: Access lending may violate RAA, says ICANN


The registrar agreements have become a joke as everybody knows ICANN
doesn't enforce it.  I have filed over 50 complaints for registrars
locking domains (mostly VeriSign) and nothing is done.  Why should
anyone expect ICANN to enforce this or any provision of the agreement?

Russ Smith




-----Original Message-----
From: owner-ga@dnso.org [mailto:owner-ga@dnso.org] On Behalf Of
Alexander Svensson
Sent: Wednesday, February 13, 2002 3:05 AM
To: DNSO General Assembly
Subject: [ga] FYI: Access lending may violate RAA, says ICANN


	
http://www.icann.org/announcements/advisory-12feb02.htm

-----------------------------------------------------------------------

Registrar Advisory Concerning Inappropriate Lending of Registry Access

Based on recent communications with registrars, it has become apparent
that
some ICANN-accredited registrars may be inappropriately lending their
access
to registries to third-party proxies. If not appropriately conducted, 
providing
registry access to third parties can violate registrars' agreements with
ICANN
and jeopardize their continued accreditation. While registrars are
permitted to
enter into reseller arrangements with agents that assist them in
providing
service to customers, registrars are not permitted otherwise to lend
access to
their connections directly to entities that are not accredited
registrars.

The purpose of this advisory is to assist registrars in understanding
their
obligations under the Registrar Accreditation Agreement (RAA) [*] in
matters
relating to lending access to entities that are not accredited
registrars.
Where appropriate, ICANN will exercise its right to audit registrar
records
in order to ensure compliance with the RAA.


Pertinent Provisions of the Registrar Accreditation Agreement

The current version of the RAA is divided into 5 sections: section 1
defines
terms; section 2 describes ICANN's obligations to registrars; section 3
describes registrars' obligations to ICANN; section 4 describes how
ICANN's
consensus process can create new policies that would be binding on
registrars;
and section 5 covers miscellaneous subjects such as termination and 
assignment.

Section 3's "Registrar Obligations" cover topics such as submission of
data to
registries, data retention requirements, public access to Whois data,
accreditation fees, and also various business requirements and
restrictions
binding on registrars. These operational mandates are set forth in
Section 
3.7,
entitled "Business Dealings, Including with Registered Name Holders."
Several
of these provisions are relevant to lending of registrar-registry
access.
These include:

  3.3.1 At its expense, Registrar shall provide an interactive web page
and a
  port 43 Whois service providing free public query-based access to
up-to-date
  (i.e., updated at least daily) data concerning all active Registered
Names
  sponsored by Registrar for each TLD in which it is accredited. ...

  3.4.2 During the Term of this Agreement and for three years
thereafter,
  Registrar (itself or by its agent(s)) shall maintain ... records
relating to
  its dealings with the Registry Operator(s) and Registered Name Holders
... .

  3.7.3 Registrar shall not represent to any actual or potential
Registered 
Name
  Holder that Registrar enjoys access to a registry for which Registrar
is
  Accredited that is superior to that of any other registrar Accredited
for 
that
  registry.

  3.7.4 Registrar shall not activate any Registered Name unless and
until 
it is
  satisfied that it has received a reasonable assurance of payment of
its
  registration fee.

  3.7.7 Registrar shall require all Registered Name Holders to enter
into an
  electronic or paper registration agreement with Registrar ... .

In summary, based on these provisions a registrar:

- must have a contract with a registrant for every domain name it
registers
   (3.7.7);

- must not "add" domains into a registry without advance assurance of
payment
   of the registration fee (3.7.4);

- must not represent that it has superior access to the registry
(3.7.3);

- must maintain a record of all registration data it submits to the
registry
   (3.4.2); and

- must provide Whois data, updated at least daily, for every domain it 
sponsors
   in the registry (3.3.1).


Registrar Access-Lending Schemes

At least one registrar access-lending scheme currently in operation
raises
significant issues under these provisions of the RAA. One registrar
recently
reported that it was unaware that it was responsible for hundreds of
domain
registrations that had been added to and then deleted from the registry 
without
the registrar's participation. The registrations had been processed
through a
machine provided by a third party that had been installed on the
registrar's
network. This registrar had agreed to install the third party's machine
in
exchange for monetary compensation paid to the registrar. The third
party was
using the machine's access to the registry to add domain registrations
into 
the
registry on behalf of the third party's customers.

Those customers had not agreed to enter into the registrar's
registration 
agreement
(in violation of RAA section 3.7.7); indeed, it appears the registrar
had no
relationship with the customers involved. The customers had not paid (or

promised
to pay) the registrar prior to the activation of the registrations (in 
violation
of 3.7.4). The registrar apparently did not have any record of the
domains 
that had
been registered (and subsequently deleted) through its systems (in 
violation of
3.4.2). Since the registrar didn't even know it had made some of the 
registrations,
it was not providing updated Whois data for those registrations (in 
violation of
3.3.1).

Overarching these other violations is a breach of section 3.7.3, which 
prohibits
registrars from representing that they have superior registry access. It

appears
that the third party has been claiming it offered the best chance to
acquire
expired names. Registrars allowing, in violation of the above
provisions, a 
third
party to enjoy the registrars' access to the registry are responsible
for the
superior-access claims that third party makes.


Permissible Registrar Wholesale/Reseller Models Distinguished

Many ICANN-accredited registrars operate or participate in
wholesale/reseller
business models that can be readily distinguished from the impermissible
access-lending schemes outlined above. In a standard registrar/reseller
model,
the registrar complies with all of the above provisions of the RAA. The 
registrar
that processes domain registrations through resellers is required to
have a
contract with every registrant, obtain assurance of payment before
activating
registrations, maintain its own records of all registration data, and
provide
public access to updated data for all domains it sponsors.


Conclusion

All ICANN-accredited registrars are strongly encouraged to undertake an 
immediate
review of any access-lending schemes in which they are currently 
participating to
ensure that they are in compliance with all of the provisions of the
Registrar
Accreditation Agreement. Registrars that continue to operate in breach
of 
the RAA
should review section 5.3 of the agreement, which covers termination of
accreditation. ICANN considers registrar compliance with accreditation 
agreements
to be a high priority. ICANN will exercise its right under Section 3.4.3
to 
audit
registrar records as appropriate.

-----------------------------------------------------------------------

[*] http://www.icann.org/registrars/ra-agreement-17may01.htm

--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html


--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html



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