Hi Karla, Do we currently have a link to the entire Base RA redline as previously requested? Will the Base RA language be going out for public comment at the same time as the draft AGB in its entirety? How long with the public comment period be? Thank you, Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com
Hi Anne, You can find the NxR Base RA redline in the working documents under Topic 36: Base RA on the SubPro IRT wiki: file:///Users/karla.hakansson/Downloads/REDLINE%20-%20Next%20Round%20Base%20RA%20Preliminary%20Working%20Draft_1%20November%202024%20(7).pdf Still TBD on the date when we post the RA for public comment. We are shooting for the end of May. The public comment period will be the standard 40 days. Best, Karla From: Anne ICANN <anneicanngnso@gmail.com> Date: Tuesday, April 29, 2025 at 15:52 To: Karla Hakansson <karla.hakansson@icann.org>, Jared Erwin via SubPro-IRT <subpro-irt@icann.org> Subject: [Ext] Base RA redline Hi Karla, Do we currently have a link to the entire Base RA redline as previously requested? Will the Base RA language be going out for public comment at the same time as the draft AGB in its entirety? How long with the public comment period be? Thank you, Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com>
Dear Anne and Susan, I know you have this covered, but if I could offer my own view as one of the former co-chairs of SubPro. I have not spoken with Cheryl about this as the other co-chair, but I would hope she would support this. I would support forwarding this on to the Council to assist in its review. During the discussions within the Subsequent Procedures PDP, the topic of “fraudulent and deceptive practices” was discussed on numerous occasions, especially earlier on during the work track phases (prior to the preliminary report). The driving force behind those discussions was a decision issued in the very first PICDRP dispute in 2017 regarding the .feedback registry. The .feedback PICDRP report (found here <https://www.icann.org/en/system/files/files/feedback-picdrp-panel-report-14m...>) was read by the working group and discussed at length. More specifically, the Panel found that the .feedback registry was engaged in fraudulent and/or deceptive practices, but neither Specification 11 nor the registry agreement itself contained a commitment, representation or covenant, that the registry would not engage in fraudulent or deceptive practices. See Exhibit A to the PICDRP report. The Working Group believed that this was an unjust result and that the next registry agreement must fix this issue so that consumers are not harmed in the future when a registry commits a fraudulent or deceptive action. Therefore it unanimously agreed to recommendation 36.4 which states: *Recommendation 36.4 *“CANN must add a contractual provision stating that the registry operator will not engage in fraudulent or deceptive practices. In the event that ICANN receives an order from a court that a registry has engaged in fraudulent or deceptive practices, ICANN may issue a notice of breach for such practices and allow the registry to cure such breach in accordance with the Registry Agreement. Further, in the event that there is a credible allegation by any third party of fraudulent or deceptive practices, other than as set forth in above, ICANN may, at its discretion, either commence dispute resolution actions under the Registry Agreement (Currently Article 5 of the Registry Agreement), or appoint a panel under the PICDRP. For the purposes of a credible claim of fraudulent or deceptive practices the reporter (as defined by the PICDRP) must only specifically state the grounds of the alleged non-compliance, but not that it personally has been harmed as a result of the registry operator’s act or omission.” It is also worth noting that neither ICANN staff nor the ICANN Board raised any issues about this recommendation in their comments to the Initial Report or to the Proposed Final Draft Report, both of which contained this recommendation. In addition, the ICANN Board of Directors adopted this recommendation without any modification. ICANN now states that they believe they have accurately captured the intent of the Recommendation 36.4. This could not be further from the truth. - First, ICANN is refusing to put a commitment in the Registry Agreement whereby the registry agrees to not engage in fraudulent or deceptive practices. Rather, it proposes to hide that commitment in a termination provision. - Second, the recommendation is clear that the promise to not engage in fraud be included in the PICDRP, which means obviously that it must be a Public Interest Commitment made by the registry. Otherwise it could not be included in the PICDRP. ICANN has refused to create such a PIC. - Third, in its proposed language in the termination section, ICANN states that it will only do so if such fraud is found by a court, a consumer protection authority, or what it deems to be a suitable arbitration. ICANN has refused to have it be subject to the PICDRP (where a third party….not ICANN…would decide if there was fraud). - Fourth, ICANN argues that we should not put ICANN in a position to determine fraud. We actually agree with this which is why SubPro recommended it be in a PICDRP, so that ICANN could choose to have a third party make that determination. ICANN has refused. What does this mean? It means that if the .feedback situation came up again, we would likely have the same unjust result. A registry would be found to have engaged in fraud by an independent panel, but ICANN and the panel would be powerless to find the registry in breach of its Registry Agreement. Like in .feedback, consumers were harmed, and ICANN stood by powerless to address. Under ICANN’s proposed language it would still be as powerless. It is also worth noting that the reason SubPro chose to go with the language it went with in the recommendation was because that language actually appears in another section of the Registry Agreement. More specifically, ICANN has imposed an obligation for registries to require registrars to have a registrant agreement that prohibits … fraudulent and deceptive practice. The irony here is that ICANN is saying that registries/registrars should police for this, but ICANN org should not. Apparently, when it concerns ICANN having to do some enforcement, it will not claiming they are not law enforcement and do not have the ability to do that type of enforcement. But apparently ICANN believes that registries and registrars do have that ability. To reiterate the SubPro Recommendation: 1. ICANN must include a provision in the Registry Agreement stating that the registry operator will not engage in fraudulent or deceptive practices. – ICANN has not done this. 2. If ICANN receives a Court Order that the registry has engaged in fraud, it may issue a notice of breach – ICANN has done this. 3. Further, in the event that there is a credible allegation by any third party of fraudulent or deceptive practices, other than as set forth in above, ICANN may, at its discretion, either commence dispute resolution actions under the Registry Agreement (Currently Article 5 of the Registry Agreement), or appoint a panel under the PICDRP. ICANN has NOT done this . Nothing requires ICANN to police for fraud. Rather, if there is a credible claim, ICANN can send it to a PICDRP for the third party to make the determination OR it can choose to Arbitrate the issue directly under Article 5 of the Registry Agreement. Sincerely, Jeff *From:* Karla Hakansson via SubPro-IRT <subpro-irt@icann.org> *Sent:* Wednesday, April 30, 2025 1:12 PM *To:* Anne ICANN <anneicanngnso@gmail.com>; Jared Erwin via SubPro-IRT < subpro-irt@icann.org> *Cc:* subpro-irt@icann.org *Subject:* [SubPro-IRT] Re: [Ext] Base RA redline Hi Anne, You can find the NxR Base RA redline in the working documents under Topic 36: Base RA on the SubPro IRT wiki: file:///Users/karla.hakansson/Downloads/REDLINE%20-%20Next%20Round%20Base%20RA%20Preliminary%20Working%20Draft_1%20November%202024%20(7).pdf Still TBD on the date when we post the RA for public comment. We are shooting for the end of May. The public comment period will be the standard 40 days. Best, Karla *From: *Anne ICANN <anneicanngnso@gmail.com> *Date: *Tuesday, April 29, 2025 at 15:52 *To: *Karla Hakansson <karla.hakansson@icann.org>, Jared Erwin via SubPro-IRT <subpro-irt@icann.org> *Subject: *[Ext] Base RA redline Hi Karla, Do we currently have a link to the entire Base RA redline as previously requested? Will the Base RA language be going out for public comment at the same time as the draft AGB in its entirety? How long with the public comment period be? Thank you, Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com
I agree Marc H. Trachtenberg Shareholder Chair, Internet, Domain Name, e-Commerce and Social Media Practice Greenberg Traurig, LLP 77 West Wacker Drive | Suite 3100 | Chicago, IL 60601 T +1 312.456.1020 M +1 773.677.3305 trac@gtlaw.com<mailto:trachtenbergm@gtlaw.com> | www.gtlaw.com<http://www.gtlaw.com/> | View GT Biography <https://www.gtlaw.com/en/professionals/t/trachtenberg-marc-h> [Greenberg Traurig Logo] [cid:image001.png@01DBB9E1.A09808A0] From: Jeff Neuman via SubPro-IRT <subpro-irt@icann.org> Sent: Wednesday, April 30, 2025 2:39 PM To: Karla Hakansson <karla.hakansson@icann.org>; Anne ICANN <anneicanngnso@gmail.com>; Jared Erwin via SubPro-IRT <subpro-irt@icann.org> Subject: [SubPro-IRT] Re: [Ext] Base RA redline *EXTERNAL TO GT* Dear Anne and Susan, I know you have this covered, but if I could offer my own view as one of the former co-chairs of SubPro. I have not spoken with Cheryl about this as the other co-chair, but I would hope she would support this. I would support forwarding this on to the Council to assist in its review. During the discussions within the Subsequent Procedures PDP, the topic of “fraudulent and deceptive practices” was discussed on numerous occasions, especially earlier on during the work track phases (prior to the preliminary report). The driving force behind those discussions was a decision issued in the very first PICDRP dispute in 2017 regarding the .feedback registry. The .feedback PICDRP report (found here<https://urldefense.com/v3/__https:/www.icann.org/en/system/files/files/feedb...>) was read by the working group and discussed at length. More specifically, the Panel found that the .feedback registry was engaged in fraudulent and/or deceptive practices, but neither Specification 11 nor the registry agreement itself contained a commitment, representation or covenant, that the registry would not engage in fraudulent or deceptive practices. See Exhibit A to the PICDRP report. The Working Group believed that this was an unjust result and that the next registry agreement must fix this issue so that consumers are not harmed in the future when a registry commits a fraudulent or deceptive action. Therefore it unanimously agreed to recommendation 36.4 which states: Recommendation 36.4 “CANN must add a contractual provision stating that the registry operator will not engage in fraudulent or deceptive practices. In the event that ICANN receives an order from a court that a registry has engaged in fraudulent or deceptive practices, ICANN may issue a notice of breach for such practices and allow the registry to cure such breach in accordance with the Registry Agreement. Further, in the event that there is a credible allegation by any third party of fraudulent or deceptive practices, other than as set forth in above, ICANN may, at its discretion, either commence dispute resolution actions under the Registry Agreement (Currently Article 5 of the Registry Agreement), or appoint a panel under the PICDRP. For the purposes of a credible claim of fraudulent or deceptive practices the reporter (as defined by the PICDRP) must only specifically state the grounds of the alleged non-compliance, but not that it personally has been harmed as a result of the registry operator’s act or omission.” It is also worth noting that neither ICANN staff nor the ICANN Board raised any issues about this recommendation in their comments to the Initial Report or to the Proposed Final Draft Report, both of which contained this recommendation. In addition, the ICANN Board of Directors adopted this recommendation without any modification. ICANN now states that they believe they have accurately captured the intent of the Recommendation 36.4. This could not be further from the truth. * First, ICANN is refusing to put a commitment in the Registry Agreement whereby the registry agrees to not engage in fraudulent or deceptive practices. Rather, it proposes to hide that commitment in a termination provision. * Second, the recommendation is clear that the promise to not engage in fraud be included in the PICDRP, which means obviously that it must be a Public Interest Commitment made by the registry. Otherwise it could not be included in the PICDRP. ICANN has refused to create such a PIC. * Third, in its proposed language in the termination section, ICANN states that it will only do so if such fraud is found by a court, a consumer protection authority, or what it deems to be a suitable arbitration. ICANN has refused to have it be subject to the PICDRP (where a third party….not ICANN…would decide if there was fraud). * Fourth, ICANN argues that we should not put ICANN in a position to determine fraud. We actually agree with this which is why SubPro recommended it be in a PICDRP, so that ICANN could choose to have a third party make that determination. ICANN has refused. What does this mean? It means that if the .feedback situation came up again, we would likely have the same unjust result. A registry would be found to have engaged in fraud by an independent panel, but ICANN and the panel would be powerless to find the registry in breach of its Registry Agreement. Like in .feedback, consumers were harmed, and ICANN stood by powerless to address. Under ICANN’s proposed language it would still be as powerless. It is also worth noting that the reason SubPro chose to go with the language it went with in the recommendation was because that language actually appears in another section of the Registry Agreement. More specifically, ICANN has imposed an obligation for registries to require registrars to have a registrant agreement that prohibits … fraudulent and deceptive practice. The irony here is that ICANN is saying that registries/registrars should police for this, but ICANN org should not. Apparently, when it concerns ICANN having to do some enforcement, it will not claiming they are not law enforcement and do not have the ability to do that type of enforcement. But apparently ICANN believes that registries and registrars do have that ability. To reiterate the SubPro Recommendation: 1. ICANN must include a provision in the Registry Agreement stating that the registry operator will not engage in fraudulent or deceptive practices. – ICANN has not done this. 2. If ICANN receives a Court Order that the registry has engaged in fraud, it may issue a notice of breach – ICANN has done this. 3. Further, in the event that there is a credible allegation by any third party of fraudulent or deceptive practices, other than as set forth in above, ICANN may, at its discretion, either commence dispute resolution actions under the Registry Agreement (Currently Article 5 of the Registry Agreement), or appoint a panel under the PICDRP. ICANN has NOT done this. Nothing requires ICANN to police for fraud. Rather, if there is a credible claim, ICANN can send it to a PICDRP for the third party to make the determination OR it can choose to Arbitrate the issue directly under Article 5 of the Registry Agreement. Sincerely, Jeff [cid:image004.png@01DBB9E1.A079F950] From: Karla Hakansson via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Sent: Wednesday, April 30, 2025 1:12 PM To: Anne ICANN <anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com>>; Jared Erwin via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Cc: subpro-irt@icann.org<mailto:subpro-irt@icann.org> Subject: [SubPro-IRT] Re: [Ext] Base RA redline Hi Anne, You can find the NxR Base RA redline in the working documents under Topic 36: Base RA on the SubPro IRT wiki: file:///Users/karla.hakansson/Downloads/REDLINE%20-%20Next%20Round%20Base%20RA%20Preliminary%20Working%20Draft_1%20November%202024%20(7).pdf Still TBD on the date when we post the RA for public comment. We are shooting for the end of May. The public comment period will be the standard 40 days. Best, Karla From: Anne ICANN <anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com>> Date: Tuesday, April 29, 2025 at 15:52 To: Karla Hakansson <karla.hakansson@icann.org<mailto:karla.hakansson@icann.org>>, Jared Erwin via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Subject: [Ext] Base RA redline Hi Karla, Do we currently have a link to the entire Base RA redline as previously requested? Will the Base RA language be going out for public comment at the same time as the draft AGB in its entirety? How long with the public comment period be? Thank you, Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com>
My recollection of the 36.4 discussion matches what Jeff mentioned in length in this thread. Rubens
Em 30 de abr. de 2025, à(s) 16:38, Jeff Neuman via SubPro-IRT <subpro-irt@icann.org> escreveu:
Dear Anne and Susan,
I know you have this covered, but if I could offer my own view as one of the former co-chairs of SubPro. I have not spoken with Cheryl about this as the other co-chair, but I would hope she would support this. I would support forwarding this on to the Council to assist in its review.
During the discussions within the Subsequent Procedures PDP, the topic of “fraudulent and deceptive practices” was discussed on numerous occasions, especially earlier on during the work track phases (prior to the preliminary report). The driving force behind those discussions was a decision issued in the very first PICDRP dispute in 2017 regarding the .feedback registry.
The .feedback PICDRP report (found here <https://www.icann.org/en/system/files/files/feedback-picdrp-panel-report-14m...>) was read by the working group and discussed at length. More specifically, the Panel found that the .feedback registry was engaged in fraudulent and/or deceptive practices, but neither Specification 11 nor the registry agreement itself contained a commitment, representation or covenant, that the registry would not engage in fraudulent or deceptive practices. See Exhibit A to the PICDRP report.
The Working Group believed that this was an unjust result and that the next registry agreement must fix this issue so that consumers are not harmed in the future when a registry commits a fraudulent or deceptive action. Therefore it unanimously agreed to recommendation 36.4 which states:
Recommendation 36.4 “CANN must add a contractual provision stating that the registry operator will not engage in fraudulent or deceptive practices. In the event that ICANN receives an order from a court that a registry has engaged in fraudulent or deceptive practices, ICANN may issue a notice of breach for such practices and allow the registry to cure such breach in accordance with the Registry Agreement. Further, in the event that there is a credible allegation by any third party of fraudulent or deceptive practices, other than as set forth in above, ICANN may, at its discretion, either commence dispute resolution actions under the Registry Agreement (Currently Article 5 of the Registry Agreement), or appoint a panel under the PICDRP. For the purposes of a credible claim of fraudulent or deceptive practices the reporter (as defined by the PICDRP) must only specifically state the grounds of the alleged non-compliance, but not that it personally has been harmed as a result of the registry operator’s act or omission.”
It is also worth noting that neither ICANN staff nor the ICANN Board raised any issues about this recommendation in their comments to the Initial Report or to the Proposed Final Draft Report, both of which contained this recommendation. In addition, the ICANN Board of Directors adopted this recommendation without any modification.
ICANN now states that they believe they have accurately captured the intent of the Recommendation 36.4. This could not be further from the truth.
First, ICANN is refusing to put a commitment in the Registry Agreement whereby the registry agrees to not engage in fraudulent or deceptive practices. Rather, it proposes to hide that commitment in a termination provision. Second, the recommendation is clear that the promise to not engage in fraud be included in the PICDRP, which means obviously that it must be a Public Interest Commitment made by the registry. Otherwise it could not be included in the PICDRP. ICANN has refused to create such a PIC. Third, in its proposed language in the termination section, ICANN states that it will only do so if such fraud is found by a court, a consumer protection authority, or what it deems to be a suitable arbitration. ICANN has refused to have it be subject to the PICDRP (where a third party….not ICANN…would decide if there was fraud). Fourth, ICANN argues that we should not put ICANN in a position to determine fraud. We actually agree with this which is why SubPro recommended it be in a PICDRP, so that ICANN could choose to have a third party make that determination. ICANN has refused.
What does this mean? It means that if the .feedback situation came up again, we would likely have the same unjust result. A registry would be found to have engaged in fraud by an independent panel, but ICANN and the panel would be powerless to find the registry in breach of its Registry Agreement. Like in .feedback, consumers were harmed, and ICANN stood by powerless to address. Under ICANN’s proposed language it would still be as powerless.
It is also worth noting that the reason SubPro chose to go with the language it went with in the recommendation was because that language actually appears in another section of the Registry Agreement. More specifically, ICANN has imposed an obligation for registries to require registrars to have a registrant agreement that prohibits … fraudulent and deceptive practice. The irony here is that ICANN is saying that registries/registrars should police for this, but ICANN org should not. Apparently, when it concerns ICANN having to do some enforcement, it will not claiming they are not law enforcement and do not have the ability to do that type of enforcement. But apparently ICANN believes that registries and registrars do have that ability.
To reiterate the SubPro Recommendation: ICANN must include a provision in the Registry Agreement stating that the registry operator will not engage in fraudulent or deceptive practices. – ICANN has not done this. If ICANN receives a Court Order that the registry has engaged in fraud, it may issue a notice of breach – ICANN has done this. Further, in the event that there is a credible allegation by any third party of fraudulent or deceptive practices, other than as set forth in above, ICANN may, at its discretion, either commence dispute resolution actions under the Registry Agreement (Currently Article 5 of the Registry Agreement), or appoint a panel under the PICDRP. ICANN has NOT done this.
Nothing requires ICANN to police for fraud. Rather, if there is a credible claim, ICANN can send it to a PICDRP for the third party to make the determination OR it can choose to Arbitrate the issue directly under Article 5 of the Registry Agreement.
Sincerely,
Jeff
<image001.png>
From: Karla Hakansson via SubPro-IRT <subpro-irt@icann.org <mailto:subpro-irt@icann.org>> Sent: Wednesday, April 30, 2025 1:12 PM To: Anne ICANN <anneicanngnso@gmail.com <mailto:anneicanngnso@gmail.com>>; Jared Erwin via SubPro-IRT <subpro-irt@icann.org <mailto:subpro-irt@icann.org>> Cc: subpro-irt@icann.org <mailto:subpro-irt@icann.org> Subject: [SubPro-IRT] Re: [Ext] Base RA redline
Hi Anne,
You can find the NxR Base RA redline in the working documents under Topic 36: Base RA on the SubPro IRT wiki: file:///Users/karla.hakansson/Downloads/REDLINE%20-%20Next%20Round%20Base%20RA%20Preliminary%20Working%20Draft_1%20November%202024%20(7).pdf
Still TBD on the date when we post the RA for public comment. We are shooting for the end of May. The public comment period will be the standard 40 days.
Best, Karla
From: Anne ICANN <anneicanngnso@gmail.com <mailto:anneicanngnso@gmail.com>> Date: Tuesday, April 29, 2025 at 15:52 To: Karla Hakansson <karla.hakansson@icann.org <mailto:karla.hakansson@icann.org>>, Jared Erwin via SubPro-IRT <subpro-irt@icann.org <mailto:subpro-irt@icann.org>> Subject: [Ext] Base RA redline
Hi Karla, Do we currently have a link to the entire Base RA redline as previously requested?
Will the Base RA language be going out for public comment at the same time as the draft AGB in its entirety? How long with the public comment period be?
Thank you, Anne
Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com <mailto:anneicanngnso@gmail.com>_______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org To unsubscribe send an email to subpro-irt-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Jeff, as I am named ;-) Please all do note as SubPro PDP Co-Chair, I concur and particularly with this from your text...
*'...ICANN now states that they believe they have accurately captured the intent of the Recommendation 36.4. This could not be further from the truth. *
- *First, ICANN is refusing to put a commitment in the Registry Agreement whereby the registry agrees to not engage in fraudulent or deceptive practices. Rather, it proposes to hide that commitment in a termination provision. *
- *Second, the recommendation is clear that the promise to not engage in fraud be included in the PICDRP, which means obviously that it must be a Public Interest Commitment made by the registry. Otherwise it could not be included in the PICDRP. ICANN has refused to create such a PIC.*
- *Third, in its proposed language in the termination section, ICANN states that it will only do so if such fraud is found by a court, a consumer protection authority, or what it deems to be a suitable arbitration. ICANN has refused to have it be subject to the PICDRP (where a third party….not ICANN…would decide if there was fraud).*
- *Fourth, ICANN argues that we should not put ICANN in a position to determine fraud. We actually agree with this which is why SubPro recommended it be in a PICDRP, so that ICANN could choose to have a third party make that determination. ICANN has refused.*
*What does this mean? It means that if the .feedback situation came up again, we would likely have the same unjust result. A registry would be found to have engaged in fraud by an independent panel, but ICANN and the panel would be powerless to find the registry in breach of its Registry Agreement. Like in .feedback, consumers were harmed, and ICANN stood by powerless to address. Under ICANN’s proposed language it would still be as powerless.... '*
<https://about.me/cheryl.LangdonOrr?promo=email_sig&utm_source=product&utm_me...> Cheryl Langdon-Orr about.me/cheryl.LangdonOrr <https://about.me/cheryl.LangdonOrr?promo=email_sig&utm_source=product&utm_me...> On Thu, 1 May 2025 at 05:39, Jeff Neuman via SubPro-IRT < subpro-irt@icann.org> wrote:
Dear Anne and Susan,
I know you have this covered, but if I could offer my own view as one of the former co-chairs of SubPro. I have not spoken with Cheryl about this as the other co-chair, but I would hope she would support this. I would support forwarding this on to the Council to assist in its review.
During the discussions within the Subsequent Procedures PDP, the topic of “fraudulent and deceptive practices” was discussed on numerous occasions, especially earlier on during the work track phases (prior to the preliminary report). The driving force behind those discussions was a decision issued in the very first PICDRP dispute in 2017 regarding the .feedback registry.
The .feedback PICDRP report (found here <https://www.icann.org/en/system/files/files/feedback-picdrp-panel-report-14m...>) was read by the working group and discussed at length. More specifically, the Panel found that the .feedback registry was engaged in fraudulent and/or deceptive practices, but neither Specification 11 nor the registry agreement itself contained a commitment, representation or covenant, that the registry would not engage in fraudulent or deceptive practices. See Exhibit A to the PICDRP report.
The Working Group believed that this was an unjust result and that the next registry agreement must fix this issue so that consumers are not harmed in the future when a registry commits a fraudulent or deceptive action. Therefore it unanimously agreed to recommendation 36.4 which states:
*Recommendation 36.4 *“CANN must add a contractual provision stating that the registry operator will not engage in fraudulent or deceptive practices. In the event that ICANN receives an order from a court that a registry has engaged in fraudulent or deceptive practices, ICANN may issue a notice of breach for such practices and allow the registry to cure such breach in accordance with the Registry Agreement. Further, in the event that there is a credible allegation by any third party of fraudulent or deceptive practices, other than as set forth in above, ICANN may, at its discretion, either commence dispute resolution actions under the Registry Agreement (Currently Article 5 of the Registry Agreement), or appoint a panel under the PICDRP. For the purposes of a credible claim of fraudulent or deceptive practices the reporter (as defined by the PICDRP) must only specifically state the grounds of the alleged non-compliance, but not that it personally has been harmed as a result of the registry operator’s act or omission.”
It is also worth noting that neither ICANN staff nor the ICANN Board raised any issues about this recommendation in their comments to the Initial Report or to the Proposed Final Draft Report, both of which contained this recommendation. In addition, the ICANN Board of Directors adopted this recommendation without any modification.
ICANN now states that they believe they have accurately captured the intent of the Recommendation 36.4. This could not be further from the truth.
- First, ICANN is refusing to put a commitment in the Registry Agreement whereby the registry agrees to not engage in fraudulent or deceptive practices. Rather, it proposes to hide that commitment in a termination provision. - Second, the recommendation is clear that the promise to not engage in fraud be included in the PICDRP, which means obviously that it must be a Public Interest Commitment made by the registry. Otherwise it could not be included in the PICDRP. ICANN has refused to create such a PIC. - Third, in its proposed language in the termination section, ICANN states that it will only do so if such fraud is found by a court, a consumer protection authority, or what it deems to be a suitable arbitration. ICANN has refused to have it be subject to the PICDRP (where a third party….not ICANN…would decide if there was fraud). - Fourth, ICANN argues that we should not put ICANN in a position to determine fraud. We actually agree with this which is why SubPro recommended it be in a PICDRP, so that ICANN could choose to have a third party make that determination. ICANN has refused.
What does this mean? It means that if the .feedback situation came up again, we would likely have the same unjust result. A registry would be found to have engaged in fraud by an independent panel, but ICANN and the panel would be powerless to find the registry in breach of its Registry Agreement. Like in .feedback, consumers were harmed, and ICANN stood by powerless to address. Under ICANN’s proposed language it would still be as powerless.
It is also worth noting that the reason SubPro chose to go with the language it went with in the recommendation was because that language actually appears in another section of the Registry Agreement. More specifically, ICANN has imposed an obligation for registries to require registrars to have a registrant agreement that prohibits … fraudulent and deceptive practice. The irony here is that ICANN is saying that registries/registrars should police for this, but ICANN org should not. Apparently, when it concerns ICANN having to do some enforcement, it will not claiming they are not law enforcement and do not have the ability to do that type of enforcement. But apparently ICANN believes that registries and registrars do have that ability.
To reiterate the SubPro Recommendation:
1. ICANN must include a provision in the Registry Agreement stating that the registry operator will not engage in fraudulent or deceptive practices. – ICANN has not done this. 2. If ICANN receives a Court Order that the registry has engaged in fraud, it may issue a notice of breach – ICANN has done this. 3. Further, in the event that there is a credible allegation by any third party of fraudulent or deceptive practices, other than as set forth in above, ICANN may, at its discretion, either commence dispute resolution actions under the Registry Agreement (Currently Article 5 of the Registry Agreement), or appoint a panel under the PICDRP. ICANN has NOT done this.
Nothing requires ICANN to police for fraud. Rather, if there is a credible claim, ICANN can send it to a PICDRP for the third party to make the determination OR it can choose to Arbitrate the issue directly under Article 5 of the Registry Agreement.
Sincerely,
Jeff
*From:* Karla Hakansson via SubPro-IRT <subpro-irt@icann.org> *Sent:* Wednesday, April 30, 2025 1:12 PM *To:* Anne ICANN <anneicanngnso@gmail.com>; Jared Erwin via SubPro-IRT < subpro-irt@icann.org> *Cc:* subpro-irt@icann.org *Subject:* [SubPro-IRT] Re: [Ext] Base RA redline
Hi Anne,
You can find the NxR Base RA redline in the working documents under Topic 36: Base RA on the SubPro IRT wiki: file:///Users/karla.hakansson/Downloads/REDLINE%20-%20Next%20Round%20Base%20RA%20Preliminary%20Working%20Draft_1%20November%202024%20(7).pdf
Still TBD on the date when we post the RA for public comment. We are shooting for the end of May. The public comment period will be the standard 40 days.
Best,
Karla
*From: *Anne ICANN <anneicanngnso@gmail.com> *Date: *Tuesday, April 29, 2025 at 15:52 *To: *Karla Hakansson <karla.hakansson@icann.org>, Jared Erwin via SubPro-IRT <subpro-irt@icann.org> *Subject: *[Ext] Base RA redline
Hi Karla,
Do we currently have a link to the entire Base RA redline as previously requested?
Will the Base RA language be going out for public comment at the same time as the draft AGB in its entirety? How long with the public comment period be?
Thank you,
Anne
Anne Aikman-Scalese
GNSO Councilor
NomCom Non-Voting 2022-2026
anneicanngnso@gmail.com _______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org To unsubscribe send an email to subpro-irt-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Cheryl and Jeff, Thanks for this excellent historical analysis. If ICANN legal and compliance were doing their job as stewards/trustees of a global resource, they would likely step up to prevent this “known” harm from happening again. Unfortunately, ICANN legal seems committed to imposing unilateral terms they conceived of independently of any community policy development process into the new baseline registry agreement. My follow-up question is directed to Kathy. The non-commercial stakeholder group has fiercely advocated for the bylaw change regarding ICANN’s prohibition on content. Do you see any scenario where ICANN would be able to determine fraud without looking at the activity (“content”) of a Registry Operator? The reason I ask this question is that I posed a similar question at WIPO’s 25th UDRP Anniversary event last week in Geneva. Specifically, I made the statement that I do not see how the UDRP could have been implemented today given the interpretation of the content provision in ICANN’s bylaws. Given that a panelist, in many instances, has to look at the content of a website to determine if the registration is in bad faith. Thanks in advance. Best regards, Michael From: Cheryl Langdon-Orr via SubPro-IRT <subpro-irt@icann.org> Date: Wednesday, April 30, 2025 at 5:37 PM To: Jeff Neuman <Jeff@jjnsolutions.com> Cc: Karla Hakansson <karla.hakansson@icann.org>, Jared Erwin via SubPro-IRT <subpro-irt@icann.org> Subject: [SubPro-IRT] Re: [Ext] Base RA redline Jeff, as I am named ;-) Please all do note as SubPro PDP Co-Chair, I concur and particularly with this from your text... '...ICANN now states that they believe they have accurately captured the intent of the Recommendation 36.4. This could not be further from the truth. * First, ICANN is refusing to put a commitment in the Registry Agreement whereby the registry agrees to not engage in fraudulent or deceptive practices. Rather, it proposes to hide that commitment in a termination provision. * Second, the recommendation is clear that the promise to not engage in fraud be included in the PICDRP, which means obviously that it must be a Public Interest Commitment made by the registry. Otherwise it could not be included in the PICDRP. ICANN has refused to create such a PIC. * Third, in its proposed language in the termination section, ICANN states that it will only do so if such fraud is found by a court, a consumer protection authority, or what it deems to be a suitable arbitration. ICANN has refused to have it be subject to the PICDRP (where a third party….not ICANN…would decide if there was fraud). * Fourth, ICANN argues that we should not put ICANN in a position to determine fraud. We actually agree with this which is why SubPro recommended it be in a PICDRP, so that ICANN could choose to have a third party make that determination. ICANN has refused. What does this mean? It means that if the .feedback situation came up again, we would likely have the same unjust result. A registry would be found to have engaged in fraud by an independent panel, but ICANN and the panel would be powerless to find the registry in breach of its Registry Agreement. Like in .feedback, consumers were harmed, and ICANN stood by powerless to address. Under ICANN’s proposed language it would still be as powerless.... ' [Image removed by sender.]<https://about.me/cheryl.LangdonOrr?promo=email_sig&utm_source=product&utm_me...> Cheryl Langdon-Orr about.me/cheryl.LangdonOrr <https://about.me/cheryl.LangdonOrr?promo=email_sig&utm_source=product&utm_me...> On Thu, 1 May 2025 at 05:39, Jeff Neuman via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> wrote: Dear Anne and Susan, I know you have this covered, but if I could offer my own view as one of the former co-chairs of SubPro. I have not spoken with Cheryl about this as the other co-chair, but I would hope she would support this. I would support forwarding this on to the Council to assist in its review. During the discussions within the Subsequent Procedures PDP, the topic of “fraudulent and deceptive practices” was discussed on numerous occasions, especially earlier on during the work track phases (prior to the preliminary report). The driving force behind those discussions was a decision issued in the very first PICDRP dispute in 2017 regarding the .feedback registry. The .feedback PICDRP report (found here<https://www.icann.org/en/system/files/files/feedback-picdrp-panel-report-14m...>) was read by the working group and discussed at length. More specifically, the Panel found that the .feedback registry was engaged in fraudulent and/or deceptive practices, but neither Specification 11 nor the registry agreement itself contained a commitment, representation or covenant, that the registry would not engage in fraudulent or deceptive practices. See Exhibit A to the PICDRP report. The Working Group believed that this was an unjust result and that the next registry agreement must fix this issue so that consumers are not harmed in the future when a registry commits a fraudulent or deceptive action. Therefore it unanimously agreed to recommendation 36.4 which states: Recommendation 36.4 “CANN must add a contractual provision stating that the registry operator will not engage in fraudulent or deceptive practices. In the event that ICANN receives an order from a court that a registry has engaged in fraudulent or deceptive practices, ICANN may issue a notice of breach for such practices and allow the registry to cure such breach in accordance with the Registry Agreement. Further, in the event that there is a credible allegation by any third party of fraudulent or deceptive practices, other than as set forth in above, ICANN may, at its discretion, either commence dispute resolution actions under the Registry Agreement (Currently Article 5 of the Registry Agreement), or appoint a panel under the PICDRP. For the purposes of a credible claim of fraudulent or deceptive practices the reporter (as defined by the PICDRP) must only specifically state the grounds of the alleged non-compliance, but not that it personally has been harmed as a result of the registry operator’s act or omission.” It is also worth noting that neither ICANN staff nor the ICANN Board raised any issues about this recommendation in their comments to the Initial Report or to the Proposed Final Draft Report, both of which contained this recommendation. In addition, the ICANN Board of Directors adopted this recommendation without any modification. ICANN now states that they believe they have accurately captured the intent of the Recommendation 36.4. This could not be further from the truth. * First, ICANN is refusing to put a commitment in the Registry Agreement whereby the registry agrees to not engage in fraudulent or deceptive practices. Rather, it proposes to hide that commitment in a termination provision. * Second, the recommendation is clear that the promise to not engage in fraud be included in the PICDRP, which means obviously that it must be a Public Interest Commitment made by the registry. Otherwise it could not be included in the PICDRP. ICANN has refused to create such a PIC. * Third, in its proposed language in the termination section, ICANN states that it will only do so if such fraud is found by a court, a consumer protection authority, or what it deems to be a suitable arbitration. ICANN has refused to have it be subject to the PICDRP (where a third party….not ICANN…would decide if there was fraud). * Fourth, ICANN argues that we should not put ICANN in a position to determine fraud. We actually agree with this which is why SubPro recommended it be in a PICDRP, so that ICANN could choose to have a third party make that determination. ICANN has refused. What does this mean? It means that if the .feedback situation came up again, we would likely have the same unjust result. A registry would be found to have engaged in fraud by an independent panel, but ICANN and the panel would be powerless to find the registry in breach of its Registry Agreement. Like in .feedback, consumers were harmed, and ICANN stood by powerless to address. Under ICANN’s proposed language it would still be as powerless. It is also worth noting that the reason SubPro chose to go with the language it went with in the recommendation was because that language actually appears in another section of the Registry Agreement. More specifically, ICANN has imposed an obligation for registries to require registrars to have a registrant agreement that prohibits … fraudulent and deceptive practice. The irony here is that ICANN is saying that registries/registrars should police for this, but ICANN org should not. Apparently, when it concerns ICANN having to do some enforcement, it will not claiming they are not law enforcement and do not have the ability to do that type of enforcement. But apparently ICANN believes that registries and registrars do have that ability. To reiterate the SubPro Recommendation: 1. ICANN must include a provision in the Registry Agreement stating that the registry operator will not engage in fraudulent or deceptive practices. – ICANN has not done this. 2. If ICANN receives a Court Order that the registry has engaged in fraud, it may issue a notice of breach – ICANN has done this. 3. Further, in the event that there is a credible allegation by any third party of fraudulent or deceptive practices, other than as set forth in above, ICANN may, at its discretion, either commence dispute resolution actions under the Registry Agreement (Currently Article 5 of the Registry Agreement), or appoint a panel under the PICDRP. ICANN has NOT done this. Nothing requires ICANN to police for fraud. Rather, if there is a credible claim, ICANN can send it to a PICDRP for the third party to make the determination OR it can choose to Arbitrate the issue directly under Article 5 of the Registry Agreement. Sincerely, Jeff [cid:image001.png@01DBB9E1.FBFDB550] From: Karla Hakansson via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Sent: Wednesday, April 30, 2025 1:12 PM To: Anne ICANN <anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com>>; Jared Erwin via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Cc: subpro-irt@icann.org<mailto:subpro-irt@icann.org> Subject: [SubPro-IRT] Re: [Ext] Base RA redline Hi Anne, You can find the NxR Base RA redline in the working documents under Topic 36: Base RA on the SubPro IRT wiki: file:///Users/karla.hakansson/Downloads/REDLINE%20-%20Next%20Round%20Base%20RA%20Preliminary%20Working%20Draft_1%20November%202024%20(7).pdf Still TBD on the date when we post the RA for public comment. We are shooting for the end of May. The public comment period will be the standard 40 days. Best, Karla From: Anne ICANN <anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com>> Date: Tuesday, April 29, 2025 at 15:52 To: Karla Hakansson <karla.hakansson@icann.org<mailto:karla.hakansson@icann.org>>, Jared Erwin via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Subject: [Ext] Base RA redline Hi Karla, Do we currently have a link to the entire Base RA redline as previously requested? Will the Base RA language be going out for public comment at the same time as the draft AGB in its entirety? How long with the public comment period be? Thank you, Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com> _______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org<mailto:subpro-irt@icann.org> To unsubscribe send an email to subpro-irt-leave@icann.org<mailto:subpro-irt-leave@icann.org> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Many thanks Cheryl. This is helpful as Susan and I are on track to bring this to Council in May. Karla has promised to provide the ICANN position to us by tomorrow May 2. Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com On Wed, Apr 30, 2025 at 2:36 PM Cheryl Langdon-Orr <langdonorr@gmail.com> wrote:
Jeff, as I am named ;-) Please all do note as SubPro PDP Co-Chair, I concur and particularly with this from your text...
*'...ICANN now states that they believe they have accurately captured the intent of the Recommendation 36.4. This could not be further from the truth. *
- *First, ICANN is refusing to put a commitment in the Registry Agreement whereby the registry agrees to not engage in fraudulent or deceptive practices. Rather, it proposes to hide that commitment in a termination provision. *
- *Second, the recommendation is clear that the promise to not engage in fraud be included in the PICDRP, which means obviously that it must be a Public Interest Commitment made by the registry. Otherwise it could not be included in the PICDRP. ICANN has refused to create such a PIC.*
- *Third, in its proposed language in the termination section, ICANN states that it will only do so if such fraud is found by a court, a consumer protection authority, or what it deems to be a suitable arbitration. ICANN has refused to have it be subject to the PICDRP (where a third party….not ICANN…would decide if there was fraud).*
- *Fourth, ICANN argues that we should not put ICANN in a position to determine fraud. We actually agree with this which is why SubPro recommended it be in a PICDRP, so that ICANN could choose to have a third party make that determination. ICANN has refused.*
*What does this mean? It means that if the .feedback situation came up again, we would likely have the same unjust result. A registry would be found to have engaged in fraud by an independent panel, but ICANN and the panel would be powerless to find the registry in breach of its Registry Agreement. Like in .feedback, consumers were harmed, and ICANN stood by powerless to address. Under ICANN’s proposed language it would still be as powerless.... '*
<https://about.me/cheryl.LangdonOrr?promo=email_sig&utm_source=product&utm_me...> Cheryl Langdon-Orr about.me/cheryl.LangdonOrr <https://about.me/cheryl.LangdonOrr?promo=email_sig&utm_source=product&utm_me...>
On Thu, 1 May 2025 at 05:39, Jeff Neuman via SubPro-IRT < subpro-irt@icann.org> wrote:
Dear Anne and Susan,
I know you have this covered, but if I could offer my own view as one of the former co-chairs of SubPro. I have not spoken with Cheryl about this as the other co-chair, but I would hope she would support this. I would support forwarding this on to the Council to assist in its review.
During the discussions within the Subsequent Procedures PDP, the topic of “fraudulent and deceptive practices” was discussed on numerous occasions, especially earlier on during the work track phases (prior to the preliminary report). The driving force behind those discussions was a decision issued in the very first PICDRP dispute in 2017 regarding the .feedback registry.
The .feedback PICDRP report (found here <https://www.icann.org/en/system/files/files/feedback-picdrp-panel-report-14m...>) was read by the working group and discussed at length. More specifically, the Panel found that the .feedback registry was engaged in fraudulent and/or deceptive practices, but neither Specification 11 nor the registry agreement itself contained a commitment, representation or covenant, that the registry would not engage in fraudulent or deceptive practices. See Exhibit A to the PICDRP report.
The Working Group believed that this was an unjust result and that the next registry agreement must fix this issue so that consumers are not harmed in the future when a registry commits a fraudulent or deceptive action. Therefore it unanimously agreed to recommendation 36.4 which states:
*Recommendation 36.4 *“CANN must add a contractual provision stating that the registry operator will not engage in fraudulent or deceptive practices. In the event that ICANN receives an order from a court that a registry has engaged in fraudulent or deceptive practices, ICANN may issue a notice of breach for such practices and allow the registry to cure such breach in accordance with the Registry Agreement. Further, in the event that there is a credible allegation by any third party of fraudulent or deceptive practices, other than as set forth in above, ICANN may, at its discretion, either commence dispute resolution actions under the Registry Agreement (Currently Article 5 of the Registry Agreement), or appoint a panel under the PICDRP. For the purposes of a credible claim of fraudulent or deceptive practices the reporter (as defined by the PICDRP) must only specifically state the grounds of the alleged non-compliance, but not that it personally has been harmed as a result of the registry operator’s act or omission.”
It is also worth noting that neither ICANN staff nor the ICANN Board raised any issues about this recommendation in their comments to the Initial Report or to the Proposed Final Draft Report, both of which contained this recommendation. In addition, the ICANN Board of Directors adopted this recommendation without any modification.
ICANN now states that they believe they have accurately captured the intent of the Recommendation 36.4. This could not be further from the truth.
- First, ICANN is refusing to put a commitment in the Registry Agreement whereby the registry agrees to not engage in fraudulent or deceptive practices. Rather, it proposes to hide that commitment in a termination provision. - Second, the recommendation is clear that the promise to not engage in fraud be included in the PICDRP, which means obviously that it must be a Public Interest Commitment made by the registry. Otherwise it could not be included in the PICDRP. ICANN has refused to create such a PIC. - Third, in its proposed language in the termination section, ICANN states that it will only do so if such fraud is found by a court, a consumer protection authority, or what it deems to be a suitable arbitration. ICANN has refused to have it be subject to the PICDRP (where a third party….not ICANN…would decide if there was fraud). - Fourth, ICANN argues that we should not put ICANN in a position to determine fraud. We actually agree with this which is why SubPro recommended it be in a PICDRP, so that ICANN could choose to have a third party make that determination. ICANN has refused.
What does this mean? It means that if the .feedback situation came up again, we would likely have the same unjust result. A registry would be found to have engaged in fraud by an independent panel, but ICANN and the panel would be powerless to find the registry in breach of its Registry Agreement. Like in .feedback, consumers were harmed, and ICANN stood by powerless to address. Under ICANN’s proposed language it would still be as powerless.
It is also worth noting that the reason SubPro chose to go with the language it went with in the recommendation was because that language actually appears in another section of the Registry Agreement. More specifically, ICANN has imposed an obligation for registries to require registrars to have a registrant agreement that prohibits … fraudulent and deceptive practice. The irony here is that ICANN is saying that registries/registrars should police for this, but ICANN org should not. Apparently, when it concerns ICANN having to do some enforcement, it will not claiming they are not law enforcement and do not have the ability to do that type of enforcement. But apparently ICANN believes that registries and registrars do have that ability.
To reiterate the SubPro Recommendation:
1. ICANN must include a provision in the Registry Agreement stating that the registry operator will not engage in fraudulent or deceptive practices. – ICANN has not done this. 2. If ICANN receives a Court Order that the registry has engaged in fraud, it may issue a notice of breach – ICANN has done this. 3. Further, in the event that there is a credible allegation by any third party of fraudulent or deceptive practices, other than as set forth in above, ICANN may, at its discretion, either commence dispute resolution actions under the Registry Agreement (Currently Article 5 of the Registry Agreement), or appoint a panel under the PICDRP. ICANN has NOT done this.
Nothing requires ICANN to police for fraud. Rather, if there is a credible claim, ICANN can send it to a PICDRP for the third party to make the determination OR it can choose to Arbitrate the issue directly under Article 5 of the Registry Agreement.
Sincerely,
Jeff
*From:* Karla Hakansson via SubPro-IRT <subpro-irt@icann.org> *Sent:* Wednesday, April 30, 2025 1:12 PM *To:* Anne ICANN <anneicanngnso@gmail.com>; Jared Erwin via SubPro-IRT < subpro-irt@icann.org> *Cc:* subpro-irt@icann.org *Subject:* [SubPro-IRT] Re: [Ext] Base RA redline
Hi Anne,
You can find the NxR Base RA redline in the working documents under Topic 36: Base RA on the SubPro IRT wiki: file:///Users/karla.hakansson/Downloads/REDLINE%20-%20Next%20Round%20Base%20RA%20Preliminary%20Working%20Draft_1%20November%202024%20(7).pdf
Still TBD on the date when we post the RA for public comment. We are shooting for the end of May. The public comment period will be the standard 40 days.
Best,
Karla
*From: *Anne ICANN <anneicanngnso@gmail.com> *Date: *Tuesday, April 29, 2025 at 15:52 *To: *Karla Hakansson <karla.hakansson@icann.org>, Jared Erwin via SubPro-IRT <subpro-irt@icann.org> *Subject: *[Ext] Base RA redline
Hi Karla,
Do we currently have a link to the entire Base RA redline as previously requested?
Will the Base RA language be going out for public comment at the same time as the draft AGB in its entirety? How long with the public comment period be?
Thank you,
Anne
Anne Aikman-Scalese
GNSO Councilor
NomCom Non-Voting 2022-2026
anneicanngnso@gmail.com _______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org To unsubscribe send an email to subpro-irt-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Thanks Jeff. Karla has promised to provide ICANN's position on the current draft language no later than tomorrow May 2. Susan and I are on track to bring this topic to Council in the May meeting. Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com On Wed, Apr 30, 2025 at 12:38 PM Jeff Neuman <Jeff@jjnsolutions.com> wrote:
Dear Anne and Susan,
I know you have this covered, but if I could offer my own view as one of the former co-chairs of SubPro. I have not spoken with Cheryl about this as the other co-chair, but I would hope she would support this. I would support forwarding this on to the Council to assist in its review.
During the discussions within the Subsequent Procedures PDP, the topic of “fraudulent and deceptive practices” was discussed on numerous occasions, especially earlier on during the work track phases (prior to the preliminary report). The driving force behind those discussions was a decision issued in the very first PICDRP dispute in 2017 regarding the .feedback registry.
The .feedback PICDRP report (found here <https://www.icann.org/en/system/files/files/feedback-picdrp-panel-report-14m...>) was read by the working group and discussed at length. More specifically, the Panel found that the .feedback registry was engaged in fraudulent and/or deceptive practices, but neither Specification 11 nor the registry agreement itself contained a commitment, representation or covenant, that the registry would not engage in fraudulent or deceptive practices. See Exhibit A to the PICDRP report.
The Working Group believed that this was an unjust result and that the next registry agreement must fix this issue so that consumers are not harmed in the future when a registry commits a fraudulent or deceptive action. Therefore it unanimously agreed to recommendation 36.4 which states:
*Recommendation 36.4 *“CANN must add a contractual provision stating that the registry operator will not engage in fraudulent or deceptive practices. In the event that ICANN receives an order from a court that a registry has engaged in fraudulent or deceptive practices, ICANN may issue a notice of breach for such practices and allow the registry to cure such breach in accordance with the Registry Agreement. Further, in the event that there is a credible allegation by any third party of fraudulent or deceptive practices, other than as set forth in above, ICANN may, at its discretion, either commence dispute resolution actions under the Registry Agreement (Currently Article 5 of the Registry Agreement), or appoint a panel under the PICDRP. For the purposes of a credible claim of fraudulent or deceptive practices the reporter (as defined by the PICDRP) must only specifically state the grounds of the alleged non-compliance, but not that it personally has been harmed as a result of the registry operator’s act or omission.”
It is also worth noting that neither ICANN staff nor the ICANN Board raised any issues about this recommendation in their comments to the Initial Report or to the Proposed Final Draft Report, both of which contained this recommendation. In addition, the ICANN Board of Directors adopted this recommendation without any modification.
ICANN now states that they believe they have accurately captured the intent of the Recommendation 36.4. This could not be further from the truth.
- First, ICANN is refusing to put a commitment in the Registry Agreement whereby the registry agrees to not engage in fraudulent or deceptive practices. Rather, it proposes to hide that commitment in a termination provision. - Second, the recommendation is clear that the promise to not engage in fraud be included in the PICDRP, which means obviously that it must be a Public Interest Commitment made by the registry. Otherwise it could not be included in the PICDRP. ICANN has refused to create such a PIC. - Third, in its proposed language in the termination section, ICANN states that it will only do so if such fraud is found by a court, a consumer protection authority, or what it deems to be a suitable arbitration. ICANN has refused to have it be subject to the PICDRP (where a third party….not ICANN…would decide if there was fraud). - Fourth, ICANN argues that we should not put ICANN in a position to determine fraud. We actually agree with this which is why SubPro recommended it be in a PICDRP, so that ICANN could choose to have a third party make that determination. ICANN has refused.
What does this mean? It means that if the .feedback situation came up again, we would likely have the same unjust result. A registry would be found to have engaged in fraud by an independent panel, but ICANN and the panel would be powerless to find the registry in breach of its Registry Agreement. Like in .feedback, consumers were harmed, and ICANN stood by powerless to address. Under ICANN’s proposed language it would still be as powerless.
It is also worth noting that the reason SubPro chose to go with the language it went with in the recommendation was because that language actually appears in another section of the Registry Agreement. More specifically, ICANN has imposed an obligation for registries to require registrars to have a registrant agreement that prohibits … fraudulent and deceptive practice. The irony here is that ICANN is saying that registries/registrars should police for this, but ICANN org should not. Apparently, when it concerns ICANN having to do some enforcement, it will not claiming they are not law enforcement and do not have the ability to do that type of enforcement. But apparently ICANN believes that registries and registrars do have that ability.
To reiterate the SubPro Recommendation:
1. ICANN must include a provision in the Registry Agreement stating that the registry operator will not engage in fraudulent or deceptive practices. – ICANN has not done this. 2. If ICANN receives a Court Order that the registry has engaged in fraud, it may issue a notice of breach – ICANN has done this. 3. Further, in the event that there is a credible allegation by any third party of fraudulent or deceptive practices, other than as set forth in above, ICANN may, at its discretion, either commence dispute resolution actions under the Registry Agreement (Currently Article 5 of the Registry Agreement), or appoint a panel under the PICDRP. ICANN has NOT done this.
Nothing requires ICANN to police for fraud. Rather, if there is a credible claim, ICANN can send it to a PICDRP for the third party to make the determination OR it can choose to Arbitrate the issue directly under Article 5 of the Registry Agreement.
Sincerely,
Jeff
*From:* Karla Hakansson via SubPro-IRT <subpro-irt@icann.org> *Sent:* Wednesday, April 30, 2025 1:12 PM *To:* Anne ICANN <anneicanngnso@gmail.com>; Jared Erwin via SubPro-IRT < subpro-irt@icann.org> *Cc:* subpro-irt@icann.org *Subject:* [SubPro-IRT] Re: [Ext] Base RA redline
Hi Anne,
You can find the NxR Base RA redline in the working documents under Topic 36: Base RA on the SubPro IRT wiki: file:///Users/karla.hakansson/Downloads/REDLINE%20-%20Next%20Round%20Base%20RA%20Preliminary%20Working%20Draft_1%20November%202024%20(7).pdf
Still TBD on the date when we post the RA for public comment. We are shooting for the end of May. The public comment period will be the standard 40 days.
Best,
Karla
*From: *Anne ICANN <anneicanngnso@gmail.com> *Date: *Tuesday, April 29, 2025 at 15:52 *To: *Karla Hakansson <karla.hakansson@icann.org>, Jared Erwin via SubPro-IRT <subpro-irt@icann.org> *Subject: *[Ext] Base RA redline
Hi Karla,
Do we currently have a link to the entire Base RA redline as previously requested?
Will the Base RA language be going out for public comment at the same time as the draft AGB in its entirety? How long with the public comment period be?
Thank you,
Anne
Anne Aikman-Scalese
GNSO Councilor
NomCom Non-Voting 2022-2026
anneicanngnso@gmail.com
All – I understand the link I shared previously may not be working. Please use this link to the Document wiki page: https://icann-community.atlassian.net/wiki/spaces/SPIR/pages/112200175/1.+Wo... Scroll to Topic 36 and look for the file name “Proposed Language Redline v01 2024-11-04” Apologies for any confusion. Karla From: Karla Hakansson <karla.hakansson@icann.org> Date: Wednesday, April 30, 2025 at 10:11 To: Anne ICANN <anneicanngnso@gmail.com>, Jared Erwin via SubPro-IRT <subpro-irt@icann.org> Cc: "subpro-irt@icann.org" <subpro-irt@icann.org> Subject: Re: [Ext] Base RA redline Hi Anne, You can find the NxR Base RA redline in the working documents under Topic 36: Base RA on the SubPro IRT wiki: file:///Users/karla.hakansson/Downloads/REDLINE%20-%20Next%20Round%20Base%20RA%20Preliminary%20Working%20Draft_1%20November%202024%20(7).pdf Still TBD on the date when we post the RA for public comment. We are shooting for the end of May. The public comment period will be the standard 40 days. Best, Karla From: Anne ICANN <anneicanngnso@gmail.com> Date: Tuesday, April 29, 2025 at 15:52 To: Karla Hakansson <karla.hakansson@icann.org>, Jared Erwin via SubPro-IRT <subpro-irt@icann.org> Subject: [Ext] Base RA redline Hi Karla, Do we currently have a link to the entire Base RA redline as previously requested? Will the Base RA language be going out for public comment at the same time as the draft AGB in its entirety? How long with the public comment period be? Thank you, Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com>
participants (7)
-
Anne ICANN -
Cheryl Langdon-Orr -
Jeff Neuman -
Karla Hakansson -
michael palage.com -
Rubens Kuhl -
trachtenbergm＠gtlaw.com