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

[Tomslin Samme-Nlar]

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> 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:
>
>    1. *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
>
>
>
>    2. *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&ouid=105988793481216121706&rtpof=true&sd=true
>
>
>
>    3. *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.
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ncuc.org/pipermail/ncuc-discuss/attachments/20240729/8c41dec5/attachment.htm>