ICANN/DNSO
DNSO Mailling lists archives

[nc-transfer]


<<< Chronological Index >>>    <<< Thread Index >>>

[nc-transfer] Draft "Supporting Arguments"


Please find to follow the first half of the "Supporting Arguments" section. I have drafted it in "FAQ" format to ensure that we draw a direct line between comments received, objections raised and questions that we answered in the report. I believe that I have captured the substantive objections, please review as quickly as you can and let me know if I have missed anything.
 
Necessarily, the second part of this document (the hard part) are the answers to these questions.
 
I'm available whenever for questions, comments etc...
 

Supporting Arguments

This portion of the Final Report is presented in “Frequently Asked Questions” format based on inquiries and comments that the Task Force receive, informally and formally, throughout the term of the Task Force. We believe that the implications raised by these questions are widely held and substantively addressed by the Policy Recommendations of the Task Force and this report.

 

Q. It appears that the Task Force only addressed the considerations raised by one proposal that was put forward by the community and not others that have been presented. Doesn’t the Task Force have a requirement to deal with all substantive proposals put forward by the community?

 

Q. The policy recommendations that you have put forth don’t seem to adequately set forth enough clarity to provide registrants, registrars and registries with the necessary level of confidence. Shouldn’t the Task Force deal with the issue of setting clear definition for all aspects of the transfers process?

 

Q. Although it was raised numerous times, the Task Force does not make any specific recommendations concerning the issue of “Apparent Authority” as it currently exists under the present policy. How does this report deal with those issues?

 

Q. Some parties like to “create their own policies” and we always therefore seem to end up with a system that can be easily gamed. How does this report deal with this issue?

 

Q. How can “third parties” authenticate transfers under these recommendations?

 

Q. Sometimes resellers and ISPs represent the registrant. Without the notion of “Apparent Authority” it will be impossible for these parties to authenticate a transfer. How is this addressed in these recommendations?

 

Q. Non-providers need to participate in the policy development process. How did the task force address the requirements of “users” (ie – registrants) during the formulation of these recommendations?

 

Q. Even when the best policies are adhered to in the strictest manner by all participants, sometimes things go wrong. With domain names, this might mean that a registrant is left without the use of their domain name for a period of time. Under the current policy, this often means that registrants have to hope for the best and put their fate in the hands of a registrar who may  or may not cooperate when it comes to “making things right”. Does this report deal with this dynamic in a meaningful way?

 

Q. Some Registrars liberally employ the “registrar_lock” function as it relates to the domain names they register for registrants. This often means that Registrant’s *can’t* transfer their domain name in a predictable way. Do the Task Force recommendations consider this?


Q. Shouldn’t the documentation procured by the Gaining Registrar be subject to some higher standard due to the influence they have over the system? If the documents that they obtained were notarized or otherwise authenticated, the process would be much more secure for Registrants.

 

Q. How closely did the Task Force follow the discussions that took place in various forums throughout the DNSO and the rest of the community?

 

Q. Doesn’t “auto-ack” simply encourage fraudulent activity to occur?

 

Q. Why don’t these recommendations protect Registrants from unscrupulous marketing practices?

 

Q. Fraudulent transfers pose a far greater problem than does “Registrar gaming” of the current policies. Why weren’t fraudulent transfers more explicitly dealt with?

 

Q. Major registrars are auto-nacking and they report that this has substantially reduced fraudulent transfers Wouldn’t allowing the losing registrar to “auto-nack” have achieved the desired results? What’s wrong with the current policy?

 

Q. The current proposal creates an incentive for gaining registrars to obtain the customer's "apparent authority" by more avenues, possibly including deceptive marketing practices, since it will allow for transfers without verification of the registrant's objective manifestation of intent to transfer.  How does the proposal address the situation where "apparent authority" is obtained by fraud or deceptive marketing? 

 

Q. This proposal is based on old thinking by the Registrar Constituency which no longer has the support of the community. Shouldn’t the Task Force allow for more time to explore alternatives?

 

Q. Won’t implementing these changes require significant alteration to the existing contracts? Should impacted parties have an opportunity to amend or negotiate these provisions before they are included in a contract?

 

Q. Won’t implementing these changes require Registry’s and Registrars to undertake significant changes to their systems and therefore incur significant costs that Registrants would ultimately be forced to bear?


<<< Chronological Index >>>    <<< Thread Index >>>