[NCUC-DISCUSS] Requesting Comments on Transfer Policy PDP Recommendations (warning...kind of a long e-mail)

Tue Jul 30 18:24:58 CEST 2024

Hi Liz. Thanks for your comment. Indeed, these changes to terminology can become very confusing! I am not sure how to address this in the context of the working group, which operates within the ICANN environment where certain terms have been defined in one way or another. But I think you raise a more fundamental question regarding the ability of different languages to capture the intended meanings! That is, perhaps, something that we can discuss within the NCSG/NCUC structure.

Ken

From: Liz Orembo <lizorembo at gmail.com> 
Sent: Monday, July 29, 2024 11:11 AM
To: Tomslin Samme-Nlar <mesumbeslin at gmail.com>
Cc: Ken Herman <ken at kherman.com>; NCSG-DISCUSS at listserv.syr.edu; NCUC-discuss <ncuc-discuss at lists.ncuc.org>
Subject: Re: [NCUC-DISCUSS] Requesting Comments on Transfer Policy PDP Recommendations (warning...kind of a long e-mail)

Thanks Ken for sharing this, and Tomslin for the reminder.

Forgive my lack of background understanding of this process.

I have only one concern/comment and perhaps there is an explanation for it. The proposed change in terminologies should at least make a universal linguistic sense among the majority of stakeholders, including tech applications. Consider Domain Name as a digital common, how the proposed name changes software such as Google translate, and the general understanding of the majority of human users whose language is not English?

Thanks!

On Mon, Jul 29, 2024 at 3:08 PM Tomslin Samme-Nlar <mesumbeslin at gmail.com <mailto:mesumbeslin at gmail.com> > wrote:

Hi all,

Just bringing this to your attention, in case you missed the email from Ken.

Warmly,

Tomslin

On Thu, 18 Jul 2024 at 22:30, Ken Herman <ken at kherman.com <mailto:ken at kherman.com> > wrote:

Dear fellow NCSG members:

Apologies in advance for the lengthy e-mail…I am soliciting comments on the preliminary recommendations of the Transfer Policy Review Working Group and there’s kind if a lot to convey. This is not the first time the NCSG is seeing much of this material, but it is a chance to see everything at once.

Since 2021, after the initiation of the PDP on Transfer Policy (TP), the TP Review working group has been considering changes to the policy that guides the transfer of domain names between registrars. 

By the end of this month the working group anticipates completing its consideration of the questions and issues raised in the charter. At that point a report with the proposed recommendations will be made available for public comment.

In this e-mail, I hope to (a) convey a sense of the recommendations and (b) solicit for any questions or comments on the recommendations prior to the public comment period. 

During my time as one of the NCSG representatives to the Working Group, I have learned about the complexity of the topic and have wondered about the best way to present this material to our community so that it is understandable yet not too dense. By presenting with numbered points rather than lengthy narratives, I hope I have reached a reasonable balance between enough and too much!

Finally, from my perspective, I did not see any major issues that had not already been addressed during the working group meetings. So, I am not seeing anything needing critical attention in these recommendations, although some of you may. In that case, please let me know.

That said, one issue that I believe bears following is in the recommendations that have to do with reasons for denying a transfer and in particular Recommendation 21. This recommendation has the potential of denying a transfer based on some considerations relating to “DNS abuse” as it is described in the Registry Accreditation Agreement. We may wish to monitor this.

Before we dive into the substance I refer to two documents:

a.	The PDF with the text of all the recommendations. The WG support staff are preparing the public report, which will contain many, many pages of explanation, justification and analysis. So this is the short version.

https://drive.google.com/file/d/1xCIkVSw-0KAUtr2Rhx1AQTsAWEgHBxc-/view?usp=sharing

b.	Blank document for your comments. This is to allow for anyone in the community to ask about the recommendation or to comment upon them, so I can convey to the working group.

https://docs.google.com/document/d/1QhSXFYYUde1Tkx6yjgZtWpH5HZ42bS5h/edit?usp=sharing <https://docs.google.com/document/d/1QhSXFYYUde1Tkx6yjgZtWpH5HZ42bS5h/edit?usp=sharing&ouid=105988793481216121706&rtpof=true&sd=true> &ouid=105988793481216121706&rtpof=true&sd=true

c.	For all background information, the TPR WG Wiki page is here: https://community.icann.org/display/TPRPDP

So, here goes…Please let me know if you have any comments, questions, or whatever. The WG plans to conclude its consideration before public comment by its last meeting on July 30, so comments before then would be appreciated. And remember, there is still the public comment period, so there is more time if issues arise.

Thanks

Ken

1.	The PDP charter called for the WG to consider a number of questions regarding the transfer policy, with the questions divided into three groups: 1(a), 1(b) and 2.

Group 1(a)

2.	In the document, recommendations 1 – 24 address the charter Group 1(a) questions.
3.	The charter requested Group 1(a) to consider the following topics:

*	Gaining Registrar Standardized Form of Authorization (FOA) and Losing Registrar FOA. The FOA is part of the mechanism that registrars use to control a domain name transfer. The charter wanted to know if these were still necessary and if there was any impact on the secure transfer of registration data, among other concerns.
*	AuthInfo Code Management. The AuthInfo code is another component of the transfer machinery, basically a token provided by the current registrar to the Registered Name Holder (RNH) to give to the new registrar to authorise the transfer. Among other issues, the charter had questions regarding the security and necessity of the AuthInfo code.
*	Wave 1, Recommendation 27. This refers to the “Final Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process” (https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-gtld-registration-data-specs-final-20feb19-en.pdf) of 2019 which addresses changes to registration data and, in recommendation 27, calls for updates in many related policies, including the transfer policy.
*	Denying Transfers (Inter-Registrar Transfers). This concerns whether or not the current reasons for denying a transfer are sufficiently clear or others are needed, as well as a consideration of aspects of the UDRP (i.e. such as the need for any additional guidance).

4.	In June 2022, a report with the recommendations associated with the Group 1(a) questions was released as “Initial Report on the Transfer Policy Review Policy Development Process - Phase 1(a)” (https://itp.cdn.icann.org/en/files/inter-registrar-transfer-policy-irtp/transfer-policy-review-initial-report-21-06-2022-en.pdf) and public comment was solicited and incorporated.
5.	Some Comments on Group 1(a) Recommendations:

*	Rec 3: Imposes a 30-day transfer restriction after registration, where prior it was inconsistently applied across registrars.
*	Recs 7 – 10 & 12 – 14: Imposes higher encryption, validation and other requirements on the transfer authorization codes for increased security.
*	Rec 11: New requirement for notification to RNH.
*	Rec 18: New specific mandatory transfer restriction after inter-registrar transfer. This alters current inconsistently-applied policy, although the revision does allow to lift the restriction under certain, very specific conditions. 
*	Recs 21 – 24: These recommendations describe the in total the list of reasons that a Registrar of Record MAY Deny a Transfer or MUST Deny a Transfer. One revision to take note of concerns “evidence of fraud”, but also refers to the Registry Accreditation Agreement”, which includes sections on threats to the DNS. This has the potential to become problematic, and so merits additional scrutiny. Also, the NCSG in previous comments raised the issue of “transfer fees” and pointed out that these can be an impediment to the non-commercial community. Nowhere in the recommendation is any mention of such fees and a registrar may only deny a transfer under the specific conditions included in the recommendation.

Group 1(b)

1.	In the document, recommendations 25 – 28 address the charter Group 1(b) questions.
2.	The charter requested Group 1(b) to consider one topic, the Change of Registrant provisions in the existing policy, including the overall policy elements and such areas as the 60-day lock (changing any registrant information automatically implemented a transfer restriction of 60 days) and the policy’s impact on Privacy/Proxy Customers and the Designated Agent mechanism.
3.	The crux of the Working Group’s recommendation consists of (a) changing the entire topic to “change of registrant data” and (b) removing these policy provisions from the transfer policy and placing them elsewhere.
4.	The working group felt that renaming the policy more accurately describes the process of making changes to the registration information associated with the name. The WG also felt that since no actual “transfer’ takes place when updating the registration information, it doesn’t belong in the transfer policy. The working group stressed that it is not recommending a new PDP to establish this standalone policy; instead, the working group is recommending the Change of Registrant Data Policy be created as part of the implementation of these policy recommendations.
5.	Some Comments on Group 1(b) Recommendations:

*	The policy includes mandatory notifications to the RNH within 25 hours of the change, and to both the previous and new e-mail addresses if that is what changes.
*	RNHs can opt out of these notifications although the default is to receive the notifications.

Group 2

1.	In the document, recommendations 29 – 47 address the charter group 2 questions.
2.	The charter requested the WG to consider the following topics within Group 2:

*	Transfer Emergency Action Contact (TEAC)(Inter-Registrar Transfers). This is the emergency contact mechanism between registrars to address critical issues with transfers.
*	Transfer Dispute Resolution Policy (Inter-Registrar Transfers). 
*	ICANN-approved Transfers. This is about voluntary full bulk and partial bulk transfers.

6.	Some Comments on Group 2 Recommendations:

*	Recs 29 – 32 are about the TEAC. The key issue is the increase on response from 4 to 24 hours. Some small registrars indicated a problem with staffing which would limit their ability to respond. On the other hand, the recommendations also call for more accountability from the receiving registrar.
*	Rec 33 calls for “further research and explore the pros and cons of (i) expanding the TDRP to registrant filers and (ii) creating a new standalone dispute resolution mechanism for registrants who wish to challenge improper transfers, including compromised and stolen domain names”
*	Recs 34 – 47 address the mechanisms behind full or partial portfolio transfers, such as when a registrar moves thousands of names. These rules provide for notification to registrants, giving them ample opportunity to transfer to their registrar of choice, and otherwise do not appear to affect registrants.

_______________________________________________
Ncuc-discuss mailing list
Ncuc-discuss at lists.ncuc.org <mailto:Ncuc-discuss at lists.ncuc.org> 
https://lists.ncuc.org/cgi-bin/mailman/listinfo/ncuc-discuss

-- 

Best regards.

Liz.

PGP ID: 0x1F3488BF

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ncuc.org/pipermail/ncuc-discuss/attachments/20240730/c9f27501/attachment.htm>