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

[Ken Herman]

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=s
haring

 

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?us
p=sharing
<https://docs.google.com/document/d/1QhSXFYYUde1Tkx6yjgZtWpH5HZ42bS5h/edit?u
sp=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/tra
nsfer-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.

 

 

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