RE: [transfers-wg] List of Issues

["Karen Lentz" <lentz@xxxxxxxxx>]

Ross and all,

Here are a few more items to add to the list:

=

1.  The term "authoritative Whois" is used in both the policy and the
dispute resolution policy, but this is not defined.  What if Whois provided
by 2 registrars conflicts?  How to proceed in dispute? 
 

2.  Related to Item 16, ICANN receives some complaints from registrants
about registrars who choose not to initiate a dispute on their behalf.
Should there be additional steps available for registrants to take if they
believe a transfer or rejection has occurred improperly? 
 

3.  Section 2.1.2.1 of the policy lists the forms of identification used in
a manual authorization process (passport, birth certificate, etc.).  This
language could be clarified to specify that faxes/scans/photocopies of these
items are acceptable.  
 

4.  Section 2.2 refers to transmitting a transfer command as specified in
the Registrar Tool Kit.  Suggest removing reference to specific RTK software
package, instead refer to transmitting transfer command as specified in the
RRP or EPP protocols. 
 

5.  Some security concerns associated with use of publicly-available email
address as authentication for electronic transfer requests.  Look at adding
further provisions for electronic signature or other alternatives.

=

Best regards,

Karen

-----Original Message-----
From: owner-transfers-wg@xxxxxxxxxxxxxx
[mailto:owner-transfers-wg@xxxxxxxxxxxxxx] On Behalf Of Thomas Keller
Sent: Tuesday, August 30, 2005 5:39 AM
To: Ross Rader
Cc: transfers-wg@xxxxxxxxxxxxxx
Subject: Re: [transfers-wg] List of Issues

Ross,

sorry for the tardiness of my remark. Could you please include
the following point.

Definition of the registrar lock function. There seems to be
some ambiguity about what can be considered as registrar lock.

Best,

tom

Am 25.08.2005 schrieb Ross Rader:
> -----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-----
> 
> 
> 

Gruss,

tom

(__)        
(OO)_____  
(oo)    /|\     A cow is not entirely full of
  | |--/ | *    milk some of it is hamburger!
  w w w  w