Transfer Policy Review - Some Final Comments

Wed Mar 5 13:07:29 EET 2025

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-tra
nsfer-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.

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