ICANN/GNSO GNSO Email List Archives

[ga]


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

[ga] "Second-Tier" registrants should not be permitted in restricted TLDs

  • To: "General Assembly of the DNSO" <ga@xxxxxxxxxxxxxx>
  • Subject: [ga] "Second-Tier" registrants should not be permitted in restricted TLDs
  • From: "Richard Henderson" <richardhenderson@xxxxxxxxxxxx>
  • Date: Fri, 25 Mar 2005 11:49:28 -0000
  • Cc: "Tim Cole" <cole@xxxxxxxxx>, <twomey@xxxxxxxxx>, "vinton g. cerf" <vinton.g.cerf@xxxxxxx>
  • Sender: owner-ga@xxxxxxxxxxxxxx

I want to propose that "leasing" of domains should not be permitted in restricted (sTLDs) where processes of authentication are required.

Quite simply, there should not be a second (unauthenticated) tier of pseudo-registrants who obtain restricted domains by this "leasing" device.

Otherwise, every sTLD may simply become a gTLD by the backdoor. The same thing that is being attempted at .Pro will be repeated at .Travel and once the principle of "leasing" has been allowed then it will be a precedent for all future sTLDs.

To put it plainly: ICANN should stipulate that their Registry Agreements for restricted TLDs are designed to limit registrations to authenticated entities, and they should say quite simply that there may only be a single tier of registration. If a registrant wishes to obtain a restricted domain, they must apply as registrant themselves, and they must be authenticated.

At the point when they cease to operate within this restricted context, the domain should not be re-sold or passed on, but should be returned to the Registry.

In short, restricted domains should be used for the purposes and contexts for which they were designed.

Nowhere in the ICANN .Pro Registry Agreement does it authorise the "leasing" of domains to what are, in effect, second-tier registrants (in the sense that they are described by EnCirca as the "owners" of the domains and they are the paying customers who are buying the domains).

ICANN should - NOW - demand that all domains obtained by this "leasing" device (invented to circumvent ICANN's own intentions) are de-activated until such time as individual registrants can get their applications and status verified. The liability for any losses incurred (in my view) lies with EnCirca in that their actions went against the expressed intentions of the Registry to restrict use, and in that they failed to consult with all parties (and specifically ICANN) over their actions which would dramatically impact on ICANN's Agreement and the commitments made to other parties (such as professionals who bought into the .Pro scheme on the original basis as it was set out). EnCirca should have consulted with ICANN first (in my view), and RegistryPro should also have consulted with ICANN within days, before activating the flood of thousands of domains which were clearly being purchased for third parties to circumvent Registry restrictions.

Meanwhile, ICANN should expressly prohibiting "leasing" of future restricted domains like .Travel... the registrant should be the real customer and should be verified; and the .Travel agreement should be amended to make this more expressly clear.

RegistryPro has allowed ICANN's purposes and intentions (as expressed in their Agreement with the Registry) to be circumvented so that, although a smiling registrar claims to stand guard over the process at the front door of the house (and is authenticated), he is actually asking thousands of unauthorised gatecrashers into the house through the back door.

Nowhere in the .Pro Agreement does it propose this process of "leasing" to subvert the intentions and processes of the Agreement. Therefore I regard the action of EnCirca and (tacitly) of RegistryPro to be in breach of the contract, in that it is a clear 'device' to subvert the principles of the Registry.

ICANN should act, and act now.
They should also act for the future, in that the precedents they allow now will also subvert other sTLDs in the future.

Yrs,

Richard Henderson


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