Introducing an Externalities Objection Process, PDDRP for all gTLDs

[Werner Staub <werner@xxxxxxxx>]

External costs (negative externalities) are the only remaining
concern for the New gTLD Program. Overall, it has been established
that external benefits of the gTLD Program exceed its external costs.
There is a way to make sure the same applies for each new gTLD
individually.

Externalities depend on the policy of the TLD operator and on the
implementation of that policy.

The right thing to do is to focus preventive action on the cases
where external costs are can occur. It is wrong to stop the
entire gTLD program because of concern about externalities from
some potential gTLDs.

The external costs can be reduced to a negligible amount if an
Externalities Objection Process is added to the gTLD program.
The Externality Objection would stop a given gTLD application
if a Panel rules that the gTLD causes unacceptable external
costs.

There are obvious guidelines as to what externalities can be
regarded as unacceptable. For instance, the weakening of the
objector’s market position cannot be regarded as an
objectionable external cost because competition is a public
policy objective. Conversely, burdens like defensive
registrations, cybersquatting and typosquatting should be
regarded as external costs.

The Panel must decide if the external costs are acceptable or
not. The burden of proof must rest upon the objector. The
objector can base its case on the Applicant’s business plan,
documented registration policy and other highly probably
properties of the proposed gTLD in question.

External costs are unacceptable if aggregate user benefits of the
proposed TLD are clearly lower than the aggregate external costs.
They are also unacceptable when the aggregate external cost is
higher than the burden the gTLD operator would have to avoid
them.

If the panel finds proof that external costs are unacceptable,
the gTLD application is rejected.

The mere possibility of making the objection brings enough
incentives for gTLD applicants to remain in the safe side. Of
course the applicant has to be held to account after delegation.
This is one more reason why the Post-Delegation Dispute
Resolution Procedure (PDDRP) should apply to all TLDs and not
just community-based TLDs.

Werner Staub