Transfer Policy Review - Some Final Comments

Thu Mar 6 11:19:02 EET 2025

Thanks Farzaneh.

If there was a statement, what I had in mind was briefly saying something like an appreciation for the consideration by the working group of issues of importance to the non-commercial community – blah blah blah – but as the world moves into a growing period of instability the risk to civil society organizations, especially those that speak out, only grows, and we call on all stakeholders in the domain name management environment to strengthen cybersecurity protections, both internally (like, do they follow any standard practices that prevent intrusion) and for their customers (more blah blah blah, like MFA).

But that’s just what comes immediately to mind. 

Ken

From: farzaneh badii <farzaneh.badii at gmail.com> 
Sent: Thursday, March 6, 2025 10:38 AM
To: Ken Herman <ken at kherman.com>
Cc: NCSG-DISCUSS at listserv.syr.edu
Subject: Re: Transfer Policy Review - Some Final Comments

Hi Ken, 

I think we provide statements when we say No or Abstain. But I think it would be a great idea to read out a short statement even if we just vote yes. 

Farzaneh 

On Thu, Mar 6, 2025 at 10:34 AM Ken Herman <ken at kherman.com <mailto:ken at kherman.com> > wrote:

Hi Rafik. Thanks for the comment. 

Short answer is, yes, I recommend that the NCSG support the report and its recommendations. The Working Group adhered to the  consensus policy, and there were no objections by any stakeholder group, and I did not hear an when I circulated the report for comment. 

That said, if it is the practice of stakeholder groups to deliver a statement at the GNSO when the report is considered, then we might consider drafting one. I can do that if needed.

Ken

From: NCSG-Discuss <NCSG-DISCUSS at LISTSERV.SYR.EDU <mailto:NCSG-DISCUSS at LISTSERV.SYR.EDU> > On Behalf Of Rafik Dammak
Sent: Thursday, March 6, 2025 7:29 AM
To: NCSG-DISCUSS at LISTSERV.SYR.EDU <mailto:NCSG-DISCUSS at LISTSERV.SYR.EDU> 
Subject: Re: Transfer Policy Review - Some Final Comments

Hi Ken,

That is a good summary and in the best timing to get more familiar with the details of those policy recommendations.

While we didn't get all of  our amendments accepted, can I assume correctly that you advice to support the recommendations at GNSO council consideration?

Best,

Rafik

On Thu, Mar 6, 2025, 03:07 Ken Herman <ken at kherman.com <mailto:ken at kherman.com> > wrote:

Greetings fellow NCSG members

With the GNSO expected to hear about the Transfer Policy Review at its meeting at ICANN82 in Seattle next week, and in response to a recent question from one of our esteemed members (Ms. Kathy K. asked for more details last month), I have compiled the following summary of outcomes of the discussions as they relate to the comments NCSG made during the public comment period, as well as a couple of observations.

Apologies for the length. As for many it might be TLDR, here are the main points:

*	Managing a domain can sometimes be complex, and registrants may benefit from guidance on selecting and working with registrars.
*	The NCSG commented on four recommendations.
*	The Working Group fully accepted comments on two of them.
*	The other two revolved around “change of registrant data”, which the working group recommended should be in a separate policy anyway.

Details below, and please feel free to let me know of any questions or comments. 

Kind regards,

Ken Herman

*****

Before getting into the details of the comments, one takeaway after this experience is the importance of education about the registration and domain name management process and practices, and the risks associated with registering a domain name and how to mitigate those risks.

The Working Group discussions clearly demonstrated that its members understood the importance of, and maintained a focus on, the security of the transfer process. However, as is common with security, there is usually a balance with cost and efficiency. When our contracted party colleagues point out that dealing with transfer problems is costly to them, I believe it! And I also believe that most businesses will make efforts to minimize those costs by being careful. However, it is also clear that there are many business model variations within the domain name industry, serving everything from individual registrants with one or a few names to those who invest in thousands, and these variations drive different management approaches, including how protective they may be. A good example was most during discussions regarding notifications and confirmations of changes. Some registrants want more notifications and confirmations, others less, and there are businesses who cater to these desires. Obviously, a potential registrant would find it beneficial to identify the registrar that meets one’s needs, and it seems that the NCSG community may wish to consider helping its members do that. 

Along these same lines, it is also clear that although the transfer process appears simple on the surface, it does contain a substantial level of underlying complexity. Within this process, the registered name holder (aka the “registrant”) has certain rights and responsibilities. The NCSG may wish to do more to educate our community regarding these rights and processes, and what to expect from the businesses that operate them, including the ICANN org’s role.

Finally, amongst the public comments, one in particular stood out by recommending an entirely different approach to transfer that, in the commentator’s opinion, would address some of the apparent inherent vulnerabilities in the existing transfer process. In short, the comment calls for a “push-based transfer system” which allegedly would provide greater control over the process by the registered name holder as well as enhanced security. The Working Group chair addressed this comment directly during the discussions, indicating that such a process is under consideration. The comment can be found here: https://www.icann.org/en/public-comment/proceeding/initial-report-on-the-transfer-policy-review-01-08-2024/submissions/leap-of-faith-financial-services-inc-29-09-2024. 

Regarding the NCSG comments, as a community we commented on four recommendations. The Working Group fully supported two of them and the other two, well, not so much. Let’s look at each of these:

Rec 18 concerned the conditions that would allow a registrar to lift a transfer restriction after an inter-registrar transfer:

*	NCSG indicated a preference that the “policy clearly articulates the acceptable exceptions, rather than the vague ‘reasonable basis for removal of the restriction’ statement” that was included in the original text. 
*	The description of the recommendation included specific reasons for lifting the restriction, such as “Legitimate circumstances surrounding an escrow intermediary affecting the completion of the acquisition of the involved registered domain name” to name one.
*	The NCSG suggested that these specific reasons be included in the text of the policy recommendation. 

Outcome: NCSG recommendation was accepted by the Working Group.

Rec 21 addressed the specific reasons that a registrar may deny a transfer request

*	One of the reasons was “Evidence of (a) fraud or (b) DNS Abuse as defined in Section 3.18.1 of the Registrar Accreditation Agreement”. 
*	NCSG pointed out that because these terms can be vague, especially with regard to DNS abuse, the policy should include some requirement for the registrar to disclose the rationale behind the refusal. 

Outcome: The working group amended the recommendation to include text that calls for the registrar to “provide specific evidence/rationale to the Registered Name Holder (RNH) upon request”.

Comment: While members of the working group generally supported the amendment, some noted that, in the case of fraud, registrars may be compelled to withhold some details. 

Rec 26 calls for the elimination of section II of the transfer policy relating to “Inter-Registrant Transfer (Change of Registrant)” and recommends the creation of a standalone “Change of Registrant Data” policy, outside of the Transfer Policy. The recommendation includes several specific changes that the new policy should include.

*	NCSG objected to two changes: (1) eliminating a requirement for a confirmation from the RNH of changes to material data and (2) eliminating a transfer restriction (aka “lock”) after the change of registrant data.
*	The NCSG expressed concerns that a simple notification of a change without confirmation and not having a restriction were actions that would not effectively safeguard the domain name.

Outcome: The NCSG suggestions were not accepted by the working group.

Comment: 

*	Although it appeared to this NCSG representative that the working group understood the concern’s expressed in the NCSG comment, the overwhelming message from the members was that, even though the data associated with a domain name may change, this did not constitute a “transfer” since the actual registration would not change, whereas a transfer to a new domain registrant would entail a registration process which has its own data requirements. 
*	Furthermore, it was pointed out that a registrar account compromise would in any event likely result in other account modifications that would undermine any change notification process. In other words, in the case of an account compromise, all bets are off! Whether this is true remains unclear.
*	It is important to note that this policy change is contained in a recommendation to create a new standalone policy, which would likely entail its own process although it remained unclear how that would proceed. In other words, this may still be able to be revisited.

Rec 27 provides details for any standalone policy regarding notifications for changes of registrant data, including how much information should a notification contain and, in particular, the mechanisms used to send the notifications, which, according to the recommendation, should be by “email, SMS, or other secure messaging system”. 

*	The NCSG called for notifications to be sent by “all” available secure means instead of “or” (although the recommendation suggests that more than one can be used).

Outcome: The NCSG suggestions were not accepted by the working group.

Comment: 

*	There were strong objections to the NCSG suggestion from amongst working group members, mainly due to the cost burden associated with utilizing multiple communication channels.
*	It was also noted again, as in Rec 26, that this was a notification of a change in registrant data, not a change in registrant, and therefore did not warrant a substantial investment in notification.
*	As in Rec 26, this policy change is contained in a recommendation to create a new standalone policy, which would likely entail its own process although it remained unclear how that would proceed. In other words, this may still be able to be revisited.

Rafik Dammak

@rafik

"fight for the users"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20250306/290e7e42/attachment.htm>