RE: [registrars] FW: [nc-transfer] Drafting Team Status Update

[Paul Stahura <stahura@enom.com>]

Ross,

I agree that the loosing registrar is best qualified to
figure out if a person has the apparent authority.
Unfortunately the loosing registrar has no incentive
to validate authority, and actually has an incentive
to screw around in the hopes of reducing market share loss
(or for whatever business purpose). 
This had been proven time and time again.  Name hostage
taking to protect market share decline, or even inadvertently
(because the email bounced, or did not get responded to for whatever
reason), 
is much more widespread than fraudulent transfers, and causes
more customer service complaints.
Auto-nack will not remove this problem.  In my opinion
it will make it worse.  If you are worried about fraudulent
transfers, allow your registrants to put their names on registrar-lock.
There is no way a name on registrar-lock can transfer.  If the gaining
registrar gets a legitimate request to transfer, the gaining
registrar can tell the name holder to go to the losing registrar
and remove the registrar-lock (the losing registrar must provide an
easy way to remove the lock by the verified name holder).
So I disagree that the solution is "auto-nack" if no response to
an attempted contact of the name holder by the losing registrar.

I also note 9) would have to change to implement Tim's suggestion.

Most fraudulent transfers that we have encountered occur when 
the bad guy gets control of a domain that was used as part
of an email address on a number of other domains.  Then the
bad guy requests transfer on *all* the other domains, acking
each email sent by both the losing and gaining registrars.
"auto-nack" does not solve this, but registrar-lock does.
Additionally, if there is an "auto-nack" policy in place, 
where is the gaining registrar redress, 
if the losing registrar abuses the "auto-nack" privilege?

I believe the root of the problem is with the RRP protocol,
and to really go a long way to solve the problem, the RRP
would need to be changed slightly (or of course switch to EPP,
even a "thin" EPP).  RRP Registrar-lock is over-loaded, 
and was not intended to solve the general transfer problem,
even though it does help solve fraudulent transfers, IMO.

It would not be too difficult for the registry to
implement an "auth code" with RRP.  The code will be
passed with each "register" command, could be modified with
the "modify" command and be required with a "transfer" command.
Only 3 commands would need to be modified.  Other Verisign
registrys have already modified the RRP in various ways
(v1.4, with .tv is one example i believe).

My comments on the document
on 5b) 
what happens when the losing registrar
blocks access to the gaining registrar's repeated requests for
the whois information?  or if the losing registrar's whois
server is down for an extended period?

I think a "blacklist of domains that must not be transferred"
is redundant.  Why not put those names on registrar lock?
Maybe I'm missing the intent here.

I think the losing registrar MAY/MUST? nack the request if the gaining
registrar notifies the losing registrar that a mistake has been 
made in the transfer initiation (an exception to 9).

is 10) the only minimum standards that apply to 9)?
10b) and 10c) do not pertain to the gaining registrar, so is
9b) really just 10a)?  
as in "9(b)	the Gaining Registrar fails to comply with  10a)"
I think i agree with the intent of 9 and 10, I just think
it could be worded clearer.
do Gaining registrars get to inspect the form of 9a) that
the losing regisrar used to deny the transfer?

I agree with Tim's suggestion 5.r below if the intent is
to prevent registrar hopping.


Paul
eNom, Inc.


-----Original Message-----
From: Tim Ruiz [mailto:tim@godaddy.com]
Sent: Wednesday, August 28, 2002 11:51 AM
To: ross@tucows.com; 'Registrar Constituency'
Subject: RE: [registrars] FW: [nc-transfer] Drafting Team Status Update


Ross,

The method of obtaining apparent authority here is backwards. In reality,
the loosing registrar is the best gauge of who truly has current apparent
authority. Registrars are not required to update their Whois information any
more often than once in 24 hours. As a result, using Whois data for the
gaining registrar to try and figure out who has apparent authority is not
safe. Requiring them to go beyond that adds undue burden on the gaining
registrar and the registrant making the request.

As a result I strongly urge that 7.f does NOT result in an ACK of the
transfer by the loosing registrar. The person with the apparent authority
according to the loosing registrar's records MUST verify the transfer
request for it to go through. Nothing else really makes sense here if one of
our goals is to truly protect the registrant from fraudulent transfers. If
the party with apparent authority confirms with the loosing registrar that
the transfer request is valid, the loosing registrar HAS confirmation then
that the gaining registrar has acquired the appropriate FOA.

I don't like the idea of counting on the gaining registrar to be honest and
complete in their dealings regarding transfers. It is too difficult, if not
impossible, to get things reversed with certain registrars. We had some
rather unpleasant dealings with one in China a few months ago on a related
issue.

If transfers are conducted in this manner, the number of instances of
registrars needing to invoke the unnecessarily complicated and time
consuming Losing Registrar Redress will be greatly reduced, if not
eliminated altogether.

In addition, I strongly urge the addition of the following v. to 5.r:

v. Request to transfer sponsorship occurs in the first 60 days after a
transfer of sponsorship.

This would add another seriously needed level of protection against fraud.
However, if the loosing registrar MUST obtain approval from someone with
apparent authority, this may not be as necessary.

Tim Ruiz
Go Daddy Software, Inc.

-----Original Message-----
From: owner-registrars@dnso.org [mailto:owner-registrars@dnso.org]On
Behalf Of Ross Wm. Rader
Sent: Wednesday, August 28, 2002 11:17 AM
To: 'Registrar Constituency'
Subject: [registrars] FW: [nc-transfer] Drafting Team Status Update


Members,

Please find to follow below a brief report on the status of the work of
the Transfers TF as it relates to Transfers. Note that we are
progressing reasonably well through a review of the Registrar
Constituency proposal and have made a few modifications that I believe
are amenable to the interests of Registrars. I had hoped at this point
that we would have received feedback from the Registry Constituency
given their renewed commitment to the issue, however I suspect that
"real life" is somehow interfering with finalizing the revisions
referenced below. I don't expect this delay to draw out in any
meaningful way (we should be able to resolve it this afternoon during
our call) but it needs to be brought to the attention of the
constituency nonetheless.

The Task Force is still targetting the Shanghai meeting for tabling of
our recommendations and we look to be in good shape at this point. If
there are any questions between now and Amsterdam, I am happy to answer
them as they come up. I expect to deliver a full progress report and
draft recommendations during the timing of the Amsterdam meeting.

Thanks in advance, (and as noted below, apologies for the proprietary
document format).



                       -rwr




"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




-----Original Message-----
From: owner-nc-transfer@dnso.org [mailto:owner-nc-transfer@dnso.org] On
Behalf Of Ross Wm. Rader
Sent: Wednesday, August 28, 2002 12:10 PM
To: 'Transfer TF (E-mail)'
Subject: [nc-transfer] Drafting Team Status Update


Folks,

Please find attached a copy of the latest draft (version 1, revision 2,
draft 2) of the IRDX proposal that the drafting team has been working on
for the last two weeks or so.

During the call today, I would like to focus on a review of points 8
through 15 (pages 14, 15 and 16) (highlighted in blue) with an eye
towards ensuring that the process appropriately takes into account the
needs of R'ants, R'rars and R'ry's. The feedback that the drafting team
gathers through this review will be invaluable in providing us with the
guidance that we need to complete our task.

I would also like to review the formal revisions made thus far to ensure
that the language used appropriately captures the intent and sentiment
of the larger group.

Please note that the revisions are not as sweeping as I had expected as
we are still waiting for input on enforcement mechanisms from the
Registry Constituency reps to the Drafting Team. I do not have an ETA
for delivery of these details, so its not likely that we can cover them
on the call, however the call will give us the capability to rework the
deadlines in order to keep the document on track

If there are any questions, please don't hesitate to drop me a note.

Apologies in advance for the proprietary document format.



                       -rwr




"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