Transfer Policy Review - Some Final Comments

[Rafik Dammak]

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> 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/c5b54510/attachment.htm>