<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [registrars] Pandora's Box (as it relates to transfers) (long)
> I am sending this note on behalf of the Registry
> Constituency. The Registry Constituency has reviewed your
> post and is very concerned that our position has been
> misstated.
Jeff - thank you for this clarification. This combined with our
telephone conversation last week clearly defines the registry
constituency position and definitively illustrates that your position is
much finer grained than the perception that you left me with on our last
two TF calls. This clarification is extremely important as the Registrar
Constituency works through the nuances of this particular issue.
That being said, there is still a substantial difference in opinion
between what Registrars and Registries expect as it relates to
enforcement, mediation and whom should assume the burden of cost. Each
of these points has a substantial impact on registrants and other
stakeholders and therefore must be the subject of continued discussion
within this TF if we are to appropriately meet our mandate of crafting a
comprehensive policy concerning inter-registrar domain name transfers.
> misstated. We believe that there is an important distinction
> to be made between enforcement of the Registry-Registrar
> Agreements (RRA) and taking on the role of arbitrator for
> registrar disputes.
I don't believe that you will find significant opposition to this point.
However, the question of where this mediative function should live still
needs to be resolved.
Further you state that
> The constituency would like to clarify its position by noting
> that the Registries do enforce its RRAs when they involve
> clear violations.
But that
> This is not to say that we are unconcerned with registrar
> compliance with the RRA, and in fact, most Registries conduct
> routine and systematic compliance evaluations. They are
> conducted, however, according to Registry internal compliance
> program guidelines, and not at the insistence of any
> particular registrar.
The limited role that Registries have chosen as it relates to the
enforcement of Exhibit B (Transfers) to the RRA is fundamentally at odds
with the needs of the registrant and registrar community. As I have
mentioned in the past, I (wearing my Registrar hat) am *currently*
dealing with tens, if not hundreds of registrants that have clear and
identifiable problems with the transfer of their registration that
cannot be resolved because the Registry Operators have chosen not to
enforce policy "at the insistence of any particular registrars" in
specific instances. This is a large problem that cannot be left
unattended any longer.
> ability to comply with equivalent access requirements. For
> these and other reasons, the RRAs include a "no third party
> beneficiaries" clause, which provides that third parties have
> no right to seek enforcement of any particular provision of
> the agreements.
If you are claiming that individual registrars are "third parties" that
have no standing to these agreements, I and most other registrars, would
take exception to this interpretation. Each registrar must sign an RRA
with each Registry Operator. In each transfer transaction, there is
clearly a "Losing Registrar" and a "Gaining Registrar". This clearly
provides a registrar party to the transaction with standing as it
relates to the agreement[1]. It has never been the contention of the
Registrar Constituency that truly unrelated third parties need standing,
but rather that both the Gaining and Losing Registrars can seek the
assistance of the Registry Operator in resolving specific issues as they
come up.
> clear violations. However, our Registry Agreements with
> ICANN do not require us to provide a forum for adjudicating
> disputes between registrars. We are not equipped to resolve
> such disputes and have no mechanism for collecting or
> requiring production of relevant information, assessing the
> relative weight, authenticity and credibility of such
> information, and rendering a decision. Imposing such
> responsibilities on Registries would not only be inconsistent
> with our essential role as a registry service provider, but
> also put us in an untenable position and jeopardize our
> ability to comply with equivalent access requirements.
This comes down to a matter of interpretation. I do note that the
Registry Constituency has arrived at an interpretation that clearly
ignores what I would characterize as "social responsibility". I bring
this up not due to a desire to be inflammatory, but simply to indicate
that there are times when a business must balance its responsibility to
its customers with its responsibility to its shareholders. I submit that
the task as you lay it out is neither nearly as difficult nor
treacherous as you imply. Notwithstanding, the request made of the
members of your constituency was not to act as a judge, but simply to
actively enforce the terms of your contracts specific situations at the
request of specific registrars. As I mentioned, the goal here is not to
determine the level of compliance or non-compliance of specific
registrars, but to resolve specific problem areas on behalf of
registrants.
> Again, all of this should be distinguished from providing
> dispute resolution services, which is what the task force is
> referring to when discussing implementation of the new
> proposed transfer policy.
This is an incorrect characterization of the TF discussion. As I
mentioned when we talked last week, we are not so much concerned about
(my bad choice of words) "mediation" but rather enforcement. Very purely
and very simply.
During the August 28th call, I described a process that "brought the
registries into the picture, that provide the registrar either/or,
losing or gaining, to appeal through ICANN (ph) or through independent
arbitration ... I don't see any reason why if we have standardized forms
of authorization ... and an agreed upon definition of appropriate
authorization and all of these other things, making these determinations
is not going to require the wisdom of Solomon ... I would much rather
take care of 80 to 90 percent of the issues that pop up day-to-day that
are very simple, but fall through the cracks because there are no
defined processes and take the remaining 10 percent ... through
arbitration ... if I could get that first 80 percent resolved."
Again, let me restate that I am not talking about "mediation" as it
relates the the registries (even though I may have used that word
loosely) - I am talking about enforcement.
> Such services are not appropriate
> at the Registry level and were definitely not contemplated in
> the existing Registry fees. Accordingly, this constituency
> takes issue with your suggestion of any Registry fee
> reduction related to this issue.
This completely misses the heart of the implications that I raised in my
last message. "If the burden of enforcement is removed from the registry
operators, then they should no longer be entitled to the portion of the
per unit funds that would normally be allocated to enforcement of the
contracts (as it specifically relates to transfers)."
Enforcement does not come without a cost. Today, this cost is borne by
the Registry Operators. If this process is moved to a third party as you
are proposing, the Registry Operators must continue to underwrite the
cost of the process to the degree that they do today, or reduce their
fee's to registrars commensurate with the costs incurred by the
community in off-loading the enforcement to a third party.
Let me be very clear - it is inappropriate to assume that Registrars
will pick up the cost of this enforcement exercise unless there are
balancing adjustments made elsewhere in the equation.
-rwr
[1]Note that I am not claiming that Registrars have privity as it
relates to these agreements, but simply that they are a party with
direct standing and interest in the agreements.
"There's a fine line between fishing and standing on the shore like an
idiot."
- Steven Wright
Got Blog? http://www.byte.org/blog
Please review our ICANN Reform Proposal:
http://www.byte.org/heathrow
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|