RE: [transfers-wg] List of Issues

["Steele, Barbara" <BSteele@xxxxxxxxxxxx>]

Thanks Ross.  This first draft looks good to me. 


Regards,
Barbara
 
Barbara Steele 
Compliance Officer
VeriSign, Inc.
21345 Ridgetop Circle
Dulles, VA  20169
Phone:  703.948.3343
Fax:  703.421.4873
Cell:  703.622.1071
 
Notice to Recipient:  This e-mail contains confidential, proprietary
and/or Registry Sensitive information intended solely for the recipient
and, thus may not be retransmitted, reproduced or disclosed without the
prior written consent of VeriSign Naming and Directory Services.  If you
have received this e-mail message in error, please notify the sender
immediately by telephone or reply e-mail and destroy the original
message without making a copy.  Thank you.

-----Original Message-----
From: owner-transfers-wg@xxxxxxxxxxxxxx
[mailto:owner-transfers-wg@xxxxxxxxxxxxxx] On Behalf Of Ross Rader
Sent: Thursday, August 25, 2005 2:31 PM
To: transfers-wg@xxxxxxxxxxxxxx
Subject: [transfers-wg] List of Issues

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Folks -

Thanks for taking the time to submit your questions, concerns and issues
with the current transfer policy. I've collated all of the comments,
verbal and written, into a single list that I'd like each of you to
review prior to the next go-round. If I have missed any input, please
let me know so that I can ensure that we've included all submissions in
the later drafts.

The next revision of this document will be used as the basis for our
next phone call. My intention is to merge this document with the SSAC
recommendations relevent to our work. This combined list will then be
turned into a matrix that outlines which issues require new policy
development, clarification of existing policy and a brief statement of
the activity and investment required to solve for each of the first two
variables (policy and clarification).

Once I've created a straw-document, we can convene a call to discuss the
matrix and make all necessary revisions required to achieve the general
buyin of this group.

If there are any questions, please let me know.

Note: I haven't edited any of these submissions for readability,
brevity, style etc. - this will come in the next draft.

Issues with New Transfer policy.

1)      Definition of the term 'transfer'. The policy states that
domains may
not be transferred 60 days after a transfer took place.  Some registrars
claim that an 'internal' transfer also falls into this category, e.g.
the domain moved from one reseller to another without registry
involvement. I do not think that this qualifies as a transfer.
Additionally it is impossible to control, so a registrar might abuse
this.

2)      Transfers in autorenew grace period. It has become a common
business
practice to use the autorenew grace period for domain monetization
programs. Usually the domain is taken offline for a few days on the day
of expiration to give the registrant time to react. If the registrant
does not react, the registrar changes the ownership data to show the
registrar as the new owner and puts some sponsored pages on the domain.
This effectively circumvents the transfer policy requirement to allow
transfer in autorenew grace period. While there are a number of
arguments pro and contra this behaviour, it is certainly not in line
with the intention of the transfer policy. We should ask ourselves if
the transfer policy has to be adopted. Add grace period abuse is a
related subject, but that is probably OT.

3)      Definition of a FOA subject line. While the FOA body is
well-defined,
the subject line is not. I think it will be easier for all participants
if the FOA would have a standardized subject line.

4)      Implementation of IANA ids for transfers. It would be an
improvement
for everyone to get rid of the proprietary registrar ids that differ
from registry to registry. CORE proposes that registries shall implement
IANA ids in transfers instead. This has already been circulated on the
RC mailing list and was endorsed by a number of people, but got lost
somehow in the .net phase.

5)      ICANN death penalty. Not sure if this is OT, but I would like to
see
more possibilities for ICANN to enforce its policies. Currently the
threat to cancel the accreditation is ICANN's only possibility to do so.
There should be more ways for ICANN. A number of proposals have been
circulated on the RC list.

6)      Default lock mechanism. OK, I know that (big) registrars are
happy
with a default domain-lock, but I still think that this is not in line
with transfer policy and that there is no need for a lock when you have
an authinfo. Hence this should be on the list of topics to address.

7)      Additional registrar imposed restrictions. It seems that a
number of
registrars are imposing additional constraints on transfers (i.e. no
transfer for 60 days after contact data changes). While the policy seems
to be rather clear on this point,  enforcement/compliance seems to be an
issue.

8)      Showing identity of reseller in FOA. As a wholesaler, we're
probably
more effected by this than most, but we are seeing a moderately high
level of confusion from end-users because their reseller isn't
identified in the FOA. It would be useful to discuss adding the option
to identify the reseller in addition to requiring the inclusion of the
registrar's identity.

9)      Repatriation of inappropriately transferred names is difficult
and
processes are still unclear. This is mostly evident in incidences where
a registrant has objected to a transfer, despite the approval of the
admin contact. The transfer policy is quite clear that the registrant
"trumps" the admin contact, but is not clear how these types of veto
situations should be handled. The result is an inconsistent application
of the policy and increased risk of domain theft.

10)     TDRP enforcement seems inconsistent and does not rely on past
precedent as intended. Situations with similar fact patterns are being
decided differently by the same dispute provider leading to a distinct
lack of clarity and reliability of the proceedings. This is primarily
observed at the registry level.

11)     Transfers immediately following a Registrant transfer (change of
ownership or license) should not be allowed, or at least, the registrar
of record should have the option of not allowing it for some period of
time, 30-60 days perhaps. This was an explicit requirement in the old
transfer policy, not sure why it was removed.

12)     Since the Registrant trumps the Admin contact there should be
some
way of automating approval from the Registrant. Currently, there is
often no Registrant email address available since it is not required to
be in the public Whois. However, I am sure most, if not all, registrars
collect that. If that could be available to registrars only when trying
to facilitate a transfer we could eliminate many conflicts later when
the Registrant claims they did not approve the transfer. Some registrars
have gone to completely paper transfer processes as a result of this
issue, and all that does is slow down and complicate the transfer
process for registrants.

13)     we should recommend that the losing registrar notice (FOA) be
required as suggested. Not that a positive response should be required,
just that it be sent.

14)     I'll take the likely unpopular view that a positive response to
a
confirmation e-mail should be required.

15)     We should consider limiting how long a registrar may hold an FOA
before submitting a transfer request.  We've run into problems when a
registrar requests a transfer a month or two after they have received
the FOA.  By that time, the registration information may have changed,
and the new registrant doesn't respond to a confirmation request (see 1
above).  Perhaps FOAs should be effective only 5 or 10 days to avoid
fraudulent transfers out.

16)     Further education is necessary for registrants and registrars to
understand where they should take their initial complaints and what the
ensuing processes will entail.

17)     Existing penalties are not sufficient deterrent (loser pays) to
discourage bad actors.

18)     Existing penalties are difficult to enforce.

19)     The term ?transfer? needs more explicit definition.

20)     It needs to be clarified whether or not registrant changes,
record
changes and the 60 day lock are appropriate reasons for denying a
transfer. Especially given the predominance of anonymous registration
services where the act of decloaking a name forces a change of contact
information and putting it in a 60 day hold.

21)     Transfer rejection messages aren?t being received. Nor are they
necessarily being sent. Registrar processes and obligations must be
clarified and implemented.

22)     Access to whois to confirm transfer requests and identity
authorizations is hit and miss. Registrar administrative requests are
sometimes being block. Privacy services exacerbate this problem.

23)     Lock is now widespread. Need more data to quantify its
effectiveness
as a security tool.

24)     Growth in private registration services will likely impact
policy.
Need to better understand trends regarding this impact. i.e. how easy it
is to transfer out of privacy enabled providers. This should be
quantified through survey.

25)     Inter-registrar communications channels and processes must be
established and streamlined to ensure a minimal capability to fix
high-impact problems in a meaningful period of time.

26)     Policy does not current deal with change of registrant. Should
it?
COR often figures heavily in hijacking cases.

27)     There are problems cleanly resolving disputes in instances where
multiple transfers have occurred. Dispute providers require further
guidance and clarification on this issue. New provisions may be needed
to deal with implications.

28)     There is no change tracking of the whois/ownership data. These
would
be very useful in resolving disputes.

29)     Dispute providers should be filing standardized reports with
ICANN
to better help the community understand trend level data regarding
resolutions.

30)     There is a lack of citations and precedent information for
dispute
providers. It would be useful if the filing party included this
information as a standard part of their submission.

31)     There is no clear definition of initial registration period.
This
should be clarified.

32)     Best practices regarding registrar lock need to be drawn out
from
current practices. Standards may need to be set regarding when use of
lock is appropriate and not appropriate.

33)     Standards for testing the reasonableness of unlock procedures
need
to be established.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)

iD8DBQFDDg516sL06XjirooRAmjpAJsEW6pW/I6Mq/AxrbiYQxoO1UKVxgCfWtt1
qjGcMspN68/L/5dcx2rOmF8=
=CDKT
-----END PGP SIGNATURE-----