[nc-transfer] Official Comments from the Registry Constituency on Transfers
All,
Here are the
comments I have received thus far from the Registry Constituency. I may
have some more before the TF Call tomorrow as well.
1) The only way that "binding policies
between registrars and registries" can be implemented is to amend registry and
registrar agreements with each other and ICANN. How does the task force think this would
happen? 2) In the Summary,
1)c) is terribly idealistic: "transfers become transactions predicated on trust
and an assumed lack of malfeasance."
When you consider the diversity among registrars and then add the
thousands of resellers to the equation, there needs to be a balance between
protection against fraud or mistakes and ease of process. 3) General Principle r) applies to EPP only and is really not a general principle but rather an explicit requirement. The TF should make it clear that this only applies to EPP-based Registries. 4) General Principle s) is not clear. What is meant by "the Losing Registrar MUST NOT employ transfer processes as a mechanism to secure payment for services from a Registrant." This seems to contradict 3)e)v) which allows a NACK of a transfer if payment has not been made for the previous period. 5) General Principle t) may need to be
reworked in order to reflect that a Registrar
should be allowed to have a LOCK service so long as the LOCK service allows the
Registrant to UNLOCK the name as well. General
Provisions: 3)d)ii) - what is a "reasonable request by the Losing Registrar." That is way to subjective and must be explicitly defined in an objectively measurable way or the words "reasonable request" should be deleted. We believe that the Gaining Registrar should ALWAYS turn over the documentation upon ANY request rather than having it be a reasonable request. Having it be only upon a "reasonable" request is too subjective and will require someone to interpret whether the request is reasonable or not. Plus, the current contracts require the gaining registrar to turn this over upon ANY request (whether or not reasonable). 3)f)iii) should probably be
qualified further. Situations where
a registrant has subscribed to
a service with the registrar to LOCK a name to prevent unauthorized transfers
and where the registrar has clear procedures for the registrant to remove that
status should probably be allowed. 3)g) - same as the comment
for 3)d)ii) above. Gaining Registrar
Processes Narrative: 5)b) - How would the accuracy of Whois data be verified after the fact? Whois data could have changed. This is especially problematic for the Non-EPP based registries. 5)k)ii) - It appears that
the FOA is not required for electronic
authorization. Is that intentional? It seems like the FOA should be required for all
authorizations or that all email authorizations should be standardized to avoid
confusion for users and ensure simplicity of the process. Optional Losing Registrar
Processes Narrative: 7)d) Probably should add
"&/or Admin Contact" after Registrant in both
places. Depending on the business model employed
by registrars, it might not always be possible to notify the
Registrant. Resolution of
Disputes: 8)b) - There are two
references to "9.a.i." What is the
correct reference? I don't think there is a
"9.a.i" in the entire document. 8)c)iii) - Depending on what
type of enforcement process is used, access to Whois and accuracy of Whois data
are required for registrars, registries and the DRP. Some steps should be taken toward this
objective (e.g., if Losing Registrar Whois is inaccessible or inaccurate, should
a transfer be allowed? Otherwise, it would be an easy way to block
transfers. 8)e)i)(1) - It seems to me
that the DRP rules drafting committee should be primarily composed of registrars
and registries instead of TF members.
It is critical to have strong involvement of those who understand
operational impacts. 8)e)iv) - I am not sure that
the DRP should decide resolution.
The DRP should only determine
whether or not the policy has been violated.
Resolution then would happen
based on the agreed to policy. 8)e)vi) - How would fees be collected? It would create a collection problem for ICANN. Registrars paying registrars directly wouldn't work. We can discuss these more tomorrow. Jeffrey J. Neuman, Esq.Director, Law & Policy NeuStar, Inc. Loudoun Tech Center 46000 Center Oak Plaza Building X Sterling, VA 20166 p: (571) 434-5772 f: (571) 434-5735 e-mail: Jeff.Neuman@Neustar.us PLEASE NOTE THE CHANGE OF ADDRESS AND TELEPHONE NUMBER AS WE HAVE MOVED FROM OUR WASHINGTON, DC OFFICE. THANKS. The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message may be an attorney-client communication and/or work product and as such is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this e-mail message and any attachments hereto in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.
|