Public Comment

Public Comment is a vital part of our multistakeholder model. It provides a mechanism for stakeholders to have their opinions and recommendations formally and publicly documented. It is an opportunity for the ICANN community to effect change and improve policies and operations.

Ce contenu est uniquement disponible en

  • English

Name: John Poole
Date: 16 Aug 2022
Affiliation: Domain Name Registrant; editor of DomainMondo.com
Are you providing input on behalf of another group (e.g., organization, company, government)?
No
Please choose your level of support for Preliminary Recommendation 1.
Significant change required: changing intent and wording

If your response requires an edit or deletion of Preliminary Recommendation 1, please indicate the revised wording and rationale here.

Preliminary Recommendation 1: The working group recommends eliminating from the Transfer Policy the requirement that the Gaining Registrar send a Gaining Form of Authorization. This requirement is detailed in section 1.A.2 of the Transfer Policy. [ADD: This recommendation is consistent with RFC 9154, which states "Registrant: [RFC8499] defines the registrant as 'an individual or organization on whose behalf a name in a zone is registered by the registry.' The registrant can be the owner of any object in the registry, such as a domain name or a contact. The registrant interfaces with the registrar for provisioning the objects. A transfer is coordinated by the registrant to transfer the sponsorship of the object from one registrar to another. The authorization information is meant to authenticate the registrant as the owner of the object to the non-sponsoring registrar and to authorize the transfer."] RATIONALE: The Working Group needs to revise its terminology and reasoning for all of its Preliminary Recommendations to be consistent with applicable RFC provisions' terminology, meaning, and intent. Use of inconsistent terminology, meaning, and intent, whether by ICANN (Org) or its so-called "ICANN community" (including registrars, registry operators, and this "Working Group") is confusing, sloppy, and inept. The proper term is "REGISTRANT," as indicated above in numerous RFC provisions, NOT "Registered Name Holder" NOR "RNH."

Please choose your level of support for Preliminary Recommendation 2.
Recommendation should be deleted

If your response requires an edit or deletion of Preliminary Recommendation 2, please indicate the revised wording and rationale here.

DELETE Preliminary Recommendation 2: "The working group recommends eliminating from the Transfer Policy the requirement that the Registrar of Record send a Losing Form of Authorization. This requirement is detailed in section I.A.3 of the Transfer Policy." RATIONALE: The Working Group's reasoning for Preliminary Recommendation 2 is severely deficient as set forth in the Initial Report. RFC 9154 is unequivocal: "A transfer is coordinated by the REGISTRANT to transfer the sponsorship of the object from one registrar to another." After-the-Fact Notice to the REGISTRANT by a REGISTRAR (which might occur if a transfer has been initiated by an unauthorized person or entity) is NOT sufficient. Therefore, any transfer coordinated by a losing registrar (or a gaining registrar), or registry, or anyone other than the REGISTRANT violates RFC 9154. The Working Group's apparent misunderstanding of the role of the REGISTRANT is hardly surprising given the apparent misunderstanding within ICANN Org generally, as indicated in its numerous attempts to re-invent or replace the word REGISTRANT, with "Registered Name Holder" or "RNH" in the Registrar Accreditation Agreement and elsewhere. See my response to Preliminary Recommendation 1 above, incorporated herein by reference. Accordingly, this recommendation needs further work to ensure the transfer is being initiated and "coordinated" by the REGISTRANT, not a registrar or registry, or unauthorized third-party, e.g., in an attempt to "steal" or "hijack" the domain name. Domain name theft, including misuse of legal processes, e.g., UDRP "Plan B" filings, as well as unlawful means, methods, and attempts to acquire domain names, is a REAL problem, as any knowledgeable REGISTRANT knows. The numerous phishing emails I receive daily as a REGISTRANT are astounding in their increasing sophistication, mimicking the "names" and "email addresses" of well-known REGISTRARS. ICANN has even, unwittingly, provided and enabled increasing incentives (e.g., tier pricing, registrar reselling, etc.) for unethical registrars and registry operators, or their personnel or affiliates, to engage in unauthorized transfers of domain names.

Please choose your level of support for Preliminary Recommendation 3.
Support Recommendation intent with wording change

If your response requires an edit or deletion of Preliminary Recommendation 3, please indicate the revised wording and rationale here.

Preliminary Recommendation 3: [Rewording shown in brackets] The working group recommends that the Registrar of Record MUST send a “Notification of TAC Provision” to the [REGISTRANT] , as listed in the Registration Data at the time of the TAC request, without undue delay but no later than 10 minutes after the Registrar of Record provides the TAC. 3.1: This notification MUST be written in the language of the registration agreement [and English], and may also be provided in other languages. 3.2: The following elements MUST be included in the “Notification of TAC Provision”: • Domain name(s) • Date and time that the TAC was provided and information about when the TAC will expire • Instructions detailing how the [REGISTRANT] can take action if the request is invalid (how to invalidate the TAC) • If the TAC has not been provided via another method of communication, this communication will include the TAC. RATIONALE: See my responses above to Preliminary Recommendations 1-2, incorporated by reference. In addition, English is "ICANN’s working language" -- https://www.icann.org/en/system/files/files/policies-procedures-18may12-en.pdf -- and the most widely spoken language in the world today -- https://www.statista.com/statistics/266808/the-most-spoken-languages-worldwide/ -- "English is the universal language of today ... the default language in international business, tourism, technology, and much more" -- https://www.berlitz.com/blog/most-spoken-languages-world . Therefore, ALL working documents required by ICANN of all its "contracted parties" should be available in English for consistency and ease of use by ICANN Contract Compliance and gTLD REGISTRANTS (English is even more predominant among gTLD Registrants than the global population as a whole according to the latest data).

Please choose your level of support for Preliminary Recommendation 4.
Support Recommendation intent with wording change

If your response requires an edit or deletion of Preliminary Recommendation 4, please indicate the revised wording and rationale here.

Preliminary Recommendation 4: [Rewording shown in brackets] The working group recommends that the Losing Registrar MUST send a “Notification of Transfer Completion”10 to the [REGISTRANT], as listed in the Registration Data at the time of the transfer request, without undue delay but no later than 24 hours after the transfer is completed. 4.1: This notification MUST be written in the language of the registration agreement and [English] and MAY also be provided in other languages. 4.2: To the extent that multiple domains have been transferred to the same Gaining Registrar or to multiple Gaining Registrars at the same time, and the [REGISTRANT] listed in the Registration Data at the time of the transfer is the same for all domains, the Registrar of Record MAY consolidate the “Notifications of Transfer Completion” into a single notification. RATIONALE: See my responses above to Preliminary Recommendations 1-3, incorporated by reference.

Question to the community: Should the Gaining Registrar’s IANA ID be provided by the Registry Operator to the Losing Registrar so that it may be included in the Notification of Transfer Completion sent by the Losing Registrar to the Registered Name Holder? Why or why not? Please explain.

Yes, include the Gaining Registrar's IANA ID so that the correct and proper party(ies) may be criminally indicted, sued, or otherwise held accountable, for any fraudulent transfers or other malfeasance that these Preliminary Recommendations, if adopted in their entirety as proposed, may enable to the detriment of all REGISTRANTS worldwide.

Please choose your level of support for Preliminary Recommendation 5.
Support Recommendation intent with wording change

If your response requires an edit or deletion of Preliminary Recommendation 5, please indicate the revised wording and rationale here.

Preliminary Recommendation 5: [ADDED wording in brackets] The working group recommends that the Transfer Policy and all related policies MUST use the term[s] “Transfer Authorization Code (TAC)” and ["REGISTRANT"] in place of the currently-used term[s] “AuthInfo Code” [and "Registered Name Holder" or "RNH", respectively,] and related terms. This recommendation is for an update to terminology only and does not imply any other changes to the substance of the policies. RATIONALE: See my responses above to Preliminary Recommendations 1-3, incorporated by reference.

Please choose your level of support for Preliminary Recommendation 6.
Support Recommendation intent with wording change

If your response requires an edit or deletion of Preliminary Recommendation 6, please indicate the revised wording and rationale here.

Preliminary Recommendation 6: [WORD CHANGE in brackets] The working group recommends that the Transfer Authorization Code MUST be defined as follows: “A Transfer Authorization Code (TAC) is a token created by the Registrar of Record and provided upon request to the [REGISTRANT] or their designated representative. The TAC is required for a domain name to be transferred from one Registrar to another Registrar and when presented authorizes the transfer.” Relevant policy language MUST be updated to be consistent with this definition. RATIONALE: See my responses above to Preliminary Recommendations 1-3, incorporated by reference.

Please choose your level of support for Preliminary Recommendation 7.
Support Recommendation as written
Please choose your level of support for Preliminary Recommendation 8.
Support Recommendation as written
Please choose your level of support for Preliminary Recommendation 9.
Support Recommendation intent with wording change

If your response requires an edit or deletion of Preliminary Recommendation 9, please indicate the revised wording and rationale here.

Replace "RNH" with "REGISTRANT" RATIONALE: See my responses above to Preliminary Recommendations 1-3, incorporated by reference.

Please choose your level of support for Preliminary Recommendation 10.
Support Recommendation as written
Please choose your level of support for Preliminary Recommendation 11.
Support Recommendation as written
Please choose your level of support for Preliminary Recommendation 12.
Support Recommendation intent with wording change

If your response requires an edit or deletion of Preliminary Recommendation 12, please indicate the revised wording and rationale here.

Replace "RNH" with "REGISTRANT" RATIONALE: See my responses above to Preliminary Recommendations 1-3, incorporated by reference.

Please choose your level of support for Preliminary Recommendation 13.
Support Recommendation intent with wording change

If your response requires an edit or deletion of Preliminary Recommendation 13, please indicate the revised wording and rationale here.

Replace "RNH" with "REGISTRANT" RATIONALE: See my responses above to Preliminary Recommendations 1-3, incorporated by reference.

Question to the community: Who is best positioned to manage the standard 14-day TTL – the Registry or the Registrar, and why? Are there specific implications if the TTL is managed by the Losing Registrar?

Response: Registrar

Rationale: 1) Registries do not have a customer relationship with Registrants, and, accordingly, having Registries preemptively invalidate a TAC directly impacts Registrants; 2) this gives Registries a compliance responsibility over Registrars since they would be required to respond to authorities and potentially Registrants investigating any concerns with the efficacy or expiry of a TAC.

Please choose your level of support for Preliminary Recommendation 14.
Support Recommendation intent with wording change

If your response requires an edit or deletion of Preliminary Recommendation 14, please indicate the revised wording and rationale here.

Replace "Registration Data" with "RDDS Data" in paragraphs (i) and (ii) for clarity, consistency, and legality, as the term "Registration Data" would be viewed as much broader under GDPR and would include, e.g., REGISTRANT's credit card data obtained and processed by the REGISTRAR as part of the domain name "Registration" and renewal processes.

Please choose your level of support for Preliminary Recommendation 15.
Support Recommendation intent with wording change

If your response requires an edit or deletion of Preliminary Recommendation 15, please indicate the revised wording and rationale here.

Replace "Registered Name Holder" with "REGISTRANT" RATIONALE: See my responses above to Preliminary Recommendations 1-3, incorporated by reference.

Please choose your level of support for Preliminary Recommendation 16.
Support Recommendation intent with wording change

If your response requires an edit or deletion of Preliminary Recommendation 16, please indicate the revised wording and rationale here.

Replace "RNH" with "REGISTRANT" RATIONALE: See my responses above to Preliminary Recommendations 1-3, incorporated by reference.

Please choose your level of support for Preliminary Recommendation 17.
Support Recommendation intent with wording change

If your response requires an edit or deletion of Preliminary Recommendation 17, please indicate the revised wording and rationale here.

Replace "RNH" with "REGISTRANT" RATIONALE: See my responses above to Preliminary Recommendations 1-3, incorporated by reference.

Please choose your level of support for Preliminary Recommendation 18.
Support Recommendation intent with wording change

If your response requires an edit or deletion of Preliminary Recommendation 18, please indicate the revised wording and rationale here.

Replace "Registered Name Holder" and "RNH" wherever they appear in the Transfer Policy with "REGISTRANT" RATIONALE: See my responses above to Preliminary Recommendations 1-3, incorporated by reference.

Please choose your level of support for Preliminary Recommendation 19.
Support Recommendation intent with wording change

If your response requires an edit or deletion of Preliminary Recommendation 19, please indicate the revised wording and rationale here.

Replace "Registered Name Holder" and "RNH" wherever they appear in the Transfer Policy with "REGISTRANT" RATIONALE: See my responses above to Preliminary Recommendations 1-3, incorporated by reference.

Please choose your level of support for Preliminary Recommendation 20.
Support Recommendation intent with wording change

If your response requires an edit or deletion of Preliminary Recommendation 20, please indicate the revised wording and rationale here.

Replace "Registered Name Holder" and "RNH" wherever they appear in the Transfer Policy with "REGISTRANT" RATIONALE: See my responses above to Preliminary Recommendations 1-3, incorporated by reference.

Please choose your level of support for Preliminary Recommendation 21.
Support Recommendation intent with wording change

If your response requires an edit or deletion of Preliminary Recommendation 21, please indicate the revised wording and rationale here.

Replace "Registered Name Holder" and "RNH" wherever they appear in the Transfer Policy with "REGISTRANT" RATIONALE: See my responses above to Preliminary Recommendations 1-3, incorporated by reference.

Please choose your level of support for Preliminary Recommendation 22.
Support Recommendation intent with wording change

If your response requires an edit or deletion of Preliminary Recommendation 22, please indicate the revised wording and rationale here.

Replace "Registered Name Holder" and "RNH" wherever they appear in the Transfer Policy with "REGISTRANT" RATIONALE: See my responses above to Preliminary Recommendations 1-3, incorporated by reference.

Are there any other comments or issues you would like to raise pertaining to the Initial Report? If yes, please enter your comments here. If applicable, please specify the section or page number in the Initial Report to which your comments refer.

The period to comment should have been extended as requested by George Kirikos. ICANN.org was offline for "maintenance" last night when I tried to finish my comment, requiring me to re-arrange my schedule today and "rush" completion of my comment by the deadline. The arrogance and hostility of ICANN, including its management and staff, and GNSO, towards most REGISTRANTS is abusive and 'beyond the pale' (see, e.g., the ICANN Ombudsman [sic] characterization of registrants' comments as "spam" in phase 1 of the .ORG Debacle referenced below). Marginalization of the vast majority of gTLD registrants is a systemic and existential problem within ICANN, at every level, including its Board of Directors, ICANN Org, and its so-called 'ICANN community' and negates ICANN's claims to be a "multi-stakeholder organization" operating in the "public interest." See, e.g., fn 5, p. 20, and fn 11, p. 31, in https://www.icann.org/en/system/files/files/irp-fegistry-et-al-icann-opp-claimant-exhibits-re-1-17-exhibits-rela-1-7-redacted-12may20-en.pdf .

Summary of Attachment


Summary of Submission

The Working Group has further critical work to do. As my comments have indicated, terminology and consistency with RFC 9154 are paramount.