<div dir="auto"><div>Hi Ken,<div dir="auto"><br></div><div dir="auto">That is a good summary and in the best timing to get more familiar with the details of those policy recommendations.</div><div dir="auto"><br></div><div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto">Best,</div><div dir="auto"><br></div><div dir="auto">Rafik</div><div dir="auto"><br></div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 6, 2025, 03:07 Ken Herman <<a href="mailto:ken@kherman.com" target="_blank" rel="noreferrer">ken@kherman.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#467886" vlink="#96607D" style="word-wrap:break-word"><div><p class="MsoNormal"><span lang="EN-GB">Greetings fellow NCSG members<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-GB">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.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-GB">Apologies for the length. As for many it might be TLDR, here are the main points:<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><ul style="margin-top:0in" type="disc"><li class="MsoNormal"><span lang="EN-GB">Managing a domain can sometimes be complex, and registrants may benefit from guidance on selecting and working with registrars.<u></u><u></u></span></li><li class="MsoNormal"><span lang="EN-GB">The NCSG commented on four recommendations.<u></u><u></u></span></li><li class="MsoNormal"><span lang="EN-GB">The Working Group fully accepted comments on two of them.<u></u><u></u></span></li><li class="MsoNormal"><span lang="EN-GB">The other two revolved around “change of registrant data”, which the working group recommended should be in a separate policy anyway.<u></u><u></u></span></li></ul><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-GB">Details below, and please feel free to let me know of any questions or comments. <u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-GB">Kind regards,<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-GB">Ken Herman<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-GB">*****<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-GB">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.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-GB">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. <u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-GB">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.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-GB">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: <a href="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" rel="noreferrer noreferrer" target="_blank">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</a>. <u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-GB">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:<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-GB">Rec 18 concerned the conditions that would allow a registrar to lift a transfer restriction after an inter-registrar transfer:<u></u><u></u></span></p><ul style="margin-top:0in" type="disc"><li class="MsoNormal"><span lang="EN-GB">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. <u></u><u></u></span></li><li class="MsoNormal"><span lang="EN-GB">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.<u></u><u></u></span></li><li class="MsoNormal"><span lang="EN-GB">The NCSG suggested that these specific reasons be included in the text of the policy recommendation. <u></u><u></u></span></li></ul><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-GB">Outcome: NCSG recommendation was accepted by the Working Group.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-GB">Rec 21 addressed the specific reasons that a registrar may deny a transfer request<u></u><u></u></span></p><ul style="margin-top:0in" type="disc"><li class="MsoNormal"><span lang="EN-GB">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”. <u></u><u></u></span></li><li class="MsoNormal"><span lang="EN-GB">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. <u></u><u></u></span></li></ul><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-GB">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”.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-GB">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. <u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-GB">Rec 26 calls for the elimination of section II of the transfer policy relating to “</span>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.<u></u><u></u></p><ul style="margin-top:0in" type="disc"><li class="MsoNormal">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.<u></u><u></u></li><li class="MsoNormal">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.<u></u><u></u></li></ul><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Outcome: The NCSG suggestions were not accepted by the working group.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Comment: <u></u><u></u></p><ul style="margin-top:0in" type="disc"><li class="MsoNormal">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. <u></u><u></u></li><li class="MsoNormal">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.<u></u><u></u></li><li class="MsoNormal">It is important to note that this policy change is contained in a recommendation to <u>create a new standalone policy</u>, 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.<u></u><u></u></li></ul><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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”. <u></u><u></u></p><ul style="margin-top:0in" type="disc"><li class="MsoNormal">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).<u></u><u></u></li></ul><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Outcome: The NCSG suggestions were not accepted by the working group.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Comment: <u></u><u></u></p><ul style="margin-top:0in" type="disc"><li class="MsoNormal">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.<u></u><u></u></li><li class="MsoNormal">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.<u></u><u></u></li><li class="MsoNormal">As in Rec 26, this policy change is contained in a recommendation to <u>create a new standalone policy</u>, 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.<u></u><u></u></li></ul><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p></div></div></blockquote></div></div><div data-smartmail="gmail_signature"><div dir="ltr"><div>Rafik Dammak</div>@rafik<div>"fight for the users"</div></div></div></div>