<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [registrars] FW: [nc-transfer] Drafting Team Status Update
Tim,
The
question then becomes WHO are you going to check with? This goes back to my
earlier issues - Registrant vs. Admin vs. who I deem as the "apparent
authority".
David
Why is it so hard to see how much less this
arbitration would be a concern, or become necessary if the losing
regitrar is at least allowed to postively verify a transfer first? The
exchange below just makes it clear how far we are away from any sort
of useful enforcement. With the proposed process, if a mistake is made
the customer potentially looses control of his/her domain for who knows how
long.
Tim
-------- Original Message --------
Subject:
Re: [registrars] FW: [nc-transfer] Drafting Team Status Update
From: "Ross
Wm. Rader" <ross@tucows.com>
Date: Mon, September 2, 2002 8:57
am
To: <tim@godaddy.com>,
<mbilow@registrationtek.com>
Tim: "We also are concerned about
the lack of enforcement of this
proposed policy and existing contractual
obligations. Adopting a
policy that is not enforceable gets us nowhere and
opens the transfer
process up to even more problems than it already
experiences."
Agreed completely Tim. The TF is cognizant of this issue.
I think that
this excerpt from the recent TF call might give you and the
membership
a better idea where we stand on this issue. Summary is that
while we
recognize the need for enforcement, the registry constituency
has
indicated that they are unwilling to take that role. Unless
their
position changes, we must start looking at alternatives like ICANN
or
third parties. Jeff Neumann's (of the Registry Constituency)
comments
seem to summon up the current "detente" quite
clearly:
"...we want none of it. We don't want to be the arbiters of
disputes
between registrars."
Jeff has committed to take the issue
back to his constituency to see
what sort of alternatives or compromises
could be explored, but so far
nothing.
[Note: Cade is
Marilyn Cade, the chair of the TF, Jeff is Jeff
Neumann, the registry
constituency delegate and chair of the registry
constituency, Ross is
myself and the <snip>'s are side-explorations of
an alternate
proposal by the IPC that doesn't fit the model cleanly]
ROSS: What I
would like to do here with the remaining time that I've
been allocated is
to start on page 14 of the document, Section eight,
and have a general
discussion that takes into account the - sort of,
the new reality that
we're faced with in adopting this as policy,
which is that it's not
appropriate - my submission is that it's not
appropriate for the losing
registrar or the gaining registrar to
enforce good policy.
Because
of the environment that this was drafted, it was viewed that
the registrar
constituency could adopt this as part of the code of
conduct and self
impose, which meant that there would literally would
be little, if any,
oversights bar the registry or ICANN (ph) in the
day-to-day execution of
theses processes.
Given that this is not going to be incorporated into
a self-regulating
code of conduct, but rather become part of the foretold
(ph) policy,
it only makes sense that those other parties - the other
parties to
the contract have some role in enforcing (ph) it (ph). So, I'd
like
to hear, generally from the group, thoughts on that so that we
can
start adapting (ph) this portion and replacing it with something
more
appropriate.
CADE: So, that would be - there would need to be
some kind of an
appeal body?
ROSS (ph): When the - when something
has gone wrong with the process
...
CADE: Right.
ROSS (ph):
... either by design or by mistake, the registrants need
ways to get the
problems fixed, gaining registrars need ways to get
domain names
transferred and losing registrars need ways to protect
their
customers.
CADE: So, there needs to be a process by which dispute - I'm
just
trying to grapple with this.
ROSS (ph): Exactly.
CADE:
There needs to be a process by which disputes can be
investigated and
somebody can play Solomon?
ROSS (ph): We need a Solomon and we need -
certainly the Solomon, but
also the default rule - the explicit statement
default rule.
CADE: Right, right. Do others have comments on this? I
think that a
- typically, Ross (ph), in the business world I sit in, where
we had
disputes with our customers, we often write into our -
extended
practice that we write into many of our contracts that we will
first
go to dispute (ph) resolution and - sometimes finding
arbitration
before we go to court.
That's pretty much business
process in the commercial business world.
ROSS (ph): I think in
instances where the information is unclear,
that would be an reasonable
last - you know, the resorting to private
contract enforcement, i.e. the
court's arbitration, is reasonable as a
last - as a last measure. I think
there is a lot that, not only the
industry can do before that, but also the
industry conduction with
ICANN (ph) can do before that to remediate these
complaints more
expediently. Certainly, the fact that we have a reasonably
expedited
process that allows intellectual property owners to protect
their
rights through the UDRP (ph) ...
CADE: Right.
ROSS
(ph): ... would indicate that as - as a community, we have what
it takes to
put together something of that nature.
CADE: And so, would that be -
that would - might be a possibility, a
uniform dispute fast track
procedure. I think it would properly need
to be even faster than the UDRP
(ph), though, really.
ROSS (ph): Yes, because the - all this while,
there is a registrant
that is being affected, either the - you know, there
is somebody at
the end of this ...
CADE: Right.
ROSS (ph):
... that doesn't have a domain name or doesn't have the
domain name they
wanted.
<snip>
CADE: What would you think - maybe instead
of solving it here, we
could think about some different models which might
be a panel of -
you know, the information would have to be blind in the
sense that,
you know, you don't know who the registry - why don't we think
about
different ideas and whether there's a role for the - do you see a
role
for the ICANN (ph) staff, Ross (ph)? The .
ROSS (ph): What I
kind of - I conceived of was something 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.
There's no -
in this conception, I don't see any reason why this
cannot be a fee for
service. These are things, you know, this kind of
mediation which is not
cheap or free, so why should the registries not
charge for it, and I don't
see any reason why if we have standardized
forms of authorization
...
CADE: Yes.
ROSS (ph): ... 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.
CADE: And then, there should be an appeals process of some -
so you
could have it rose (ph) and regionalized (ph) and then have a pass
to
appeal.
ROSS (ph): 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 to the math and spend a year working through
the
courts just through
arbitration on them, if I could get that first
80 percent resolved.
JEFF (ph): Can I just say that the registry has,
in the past,
discussed this issue because it's come up several times as
should the
registries be one that looks at this. And I can just tell you
from
the registry constituency standpoint, we want none of it. We
don't
want to be the arbiters of disputes between registrars. And
certainly
a fee that we would charge would be - not because we want to
make
money off of it, but any fee that we would charge would be much
higher
than anybody would probably want to pay.
ROSS (ph): But Jeff
(ph), the reality of the situation is ...
CADE: . wait, wait
...
<snip>
CADE: Jeff (ph), are you guys resistant because
of liability?
JEFF (ph): Well, that's a big issue, yes. But it's also -
it's not
something we want to do ...
ROSS (ph): Well, Jeff (ph)
...
JEFF (ph): . we are not arbiters.
ROSS (ph): The fact of the
matter is though that you and ICANN (ph)
are literally the only party in
this entire process that has
sufficient standing to do any sort of
enforcement whatsoever. So, I
don't understand where this reticence comes
from; there was a
willingness to sign the contracts that gave you that
oversight
responsibility, but there's no willingness to assume that
enforcement
responsibility. So, I would question our ability to even come
up with
a reasonable policy is
...
Thanks,
-rwr
Got Blog?
http://www.byte.org/blog
"People demand freedom of speech as a
compensation for the freedom of
thought which they seldom use."
- Soren
Kierkegaard
----- Original Message -----
From: "Tim Ruiz"
<tim@godaddy.com>
To: <mbilow@registrationtek.com>
Cc:
<ross@tucows.com>; <registrars@dnso.org>
Sent: Monday,
September 02, 2002 8:40 AM
Subject: RE: [registrars] FW: [nc-transfer]
Drafting Team Status
Update
> Mike,
>
> Very well
put. We agree completely. There is no way that it is
> appropriate
to
attempt to tie the losing registrar's hands in this matter in favor
of the
gaining registrar under the false impression that it is somehow
better for
the registrant. We also are concerned about the lack of
enforcement of this
proposed policy and existing contractual
obligations. Adopting a policy
that is not enforceable gets us nowhere
and opens the transfer process up
to even more problems than it
already experiences.
>
> Tim
Ruiz
> Go Daddy Software, Inc.
>
> -------- Original Message
--------
> Subject: RE: [registrars] FW: [nc-transfer] Drafting Team
Status
> Update From: Michael Bilow
<mbilow@registrationtek.com>
> Date: Mon, September 2, 2002 1:59
am
> To: "Ross Wm. Rader" <ross@tucows.com>
>
> On
2002-08-30 at 13:42 -0400, Ross Wm. Rader wrote:
>
> > The
draft policy generally contemplates the following;
> >
> >
1. That the default rule on a transfer request from the registry
> >
to the losing registrar should be an "ack" in all cases unless the
>
> losing registrar has explicit knowledge that the registrant does
>
> not wish to undertake the transfer.
>
> What about the case
where a determined hijacker repeatedly puts in
> transfer requests for a
domain name? The registrant would be
> expected to affirm repeatedly
that they disapprove each transfer.
> One could argue that in such a
case the current registrar has
> explicit
> knowledge, but that's
not the kind of thing that could easily be
> automated. Locking the
domain at the registry would also help in
> such cases, but this still
places the burden on the legitimate
> registrant, and that is unfair: if
the legitimate registrant messes
> up even once, or they have a problem
with their e-mail, or someone
> takes a vacation, or the contact for the
domain is naive and
> unsophisticated, the domain might inappropriately
transfer.
>
> Even saying that the burden rests with the
requesting registrar is
> no solution, since presumably a hijacker would
give whatever false
> assurances were requested and could move from one
registrar to
> another, creating fake accounts and doing all sort of
other
> underhanded things. In the face of this, it really seems
>
inappropriate to burden the legitimate registrant.
>
> > 2.
That the gaining registrar must only initiate the transfer
> >
process with the explicit consent of the registrant or an entity
> >
that the registrar reasonably believes has the authority to act on
>
> the
> > registrants behalf.
>
> This is the core of
the problem: the gaining registrar has no real
> way to determine this.
On the one hand, the registrar can tell the
> customer that initiating a
request to transfer a domain is a claim
> of apparent
> authority,
and can ask the customer to affirm such authority. Our
> procedure is to
make the customer check a box on a web form which
> makes this claim
under penalty of perjury. Obviously, someone could
> lie, but it gives
us a little more leverage in undoing an improper
> transfer should we
decide that our own customer wrongly requested
> it.
>
> On
the other hand, the majority of transfer requests are legitimate,
> and
putting a lot of obstacles in the way is unfair as well.
>
> What
I am particularly leery about is the possibility that two
> competing
claimants for apparent authority will use registrars as
> proxies to
fight their dispute. If this kind of thing happens, the
> gaining
registrar is likely to end up one of the defendants.
>
> > 3.
(This one is perhaps the most important) That the processes
> >
employed by registrars to undertake these types of transactions
> >
are registrant friendly and do not require the implementation of
> >
bureaucratic artifice such as double acknowledgements, artificial
> >
barriers to portability etc. In other words, the processes might
> >
be complex for registrars to carry out, but simple for registrants
>
> to deal with - "designed for the consumer" in other words -
> >
simple, efficient and safe.
>
> Where we draw the line is between
those cases which can be processed
> automatically and those which
cannot. For the tiny minority of cases
> which cannot, our approach is
to involve a real human who can apply
> reasonable common sense and
decision making skills. Trying to
> oversimplify this into a set of
rigid rules is really impossible:
> the losing registrar has, I think, a
clear duty to confirm the
> intent of the registrant before allowing the
transfer. We do not
> request a notarized affidavit and a DNA sample,
but we apply
> whatever methods are appropriate to resolve the
uncertainty we
> believe is present in a particular
case.
>
> I concede that this duty of the losing registrar is in
addition to
> the duty of the gaining registrar to confirm apparent
authority
> before initiating the request, but such duty of the losing
registrar
> seems to exist nonetheless. Trying to constrain the losing
registrar
> into refusing a transfer only on the basis of "explicit
knowledge"
> of the registrant's contrary intent would introduce very
serious
> complexities and subtleties.
>
> --
Mike
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|