Hi Mike, This is an issue that I (and the small team) spent a lot of time trying to reconcile: the desires of registrars to be able to deny transfers for registration agreement violations (which in theory could be something other than fraud or illegal or abusive, but still very objectionable), and those of NCSG (and myself) about being able to deny a transfer for any minor breach of the registration agreement. We compromised and decided to include this implementation guidance in the report, which will need to be included in a final report (and thus form basis of any eventual policy): Implementation Guidance: The intent of “violation of the Registration Agreement” is not to allow the blocking of transfers due to minor violations, but to allow action in case of substantive contravention of the Registration Agreement. We also provided a rationale in the notes, which will also carry forward into the final report: The working group noted that such abusive activities typically constitute a violation of the Registration Agreement, and therefore by including “violation of the Registration Agreement” to the reasons that the Registrar of Record MAY deny a transfer, the Policy will explicitly permit denials in these circumstances. The Implementation Guidance provides additional “guardrails” to protect against denial of transfers for minor, inadvertent violations of the Registration Agreement. The Working Group notes that Registration Agreement violations have in the past formed the basis of formal ICANN Compliance enforcement relating to domain transfer. I pushed hard to ensure the guardrails, because of the referenced Compliance case. I cannot provide further details (as they remain confidential), but basically agreeing to the registration agreement (and its problematic wording) would have immediately subjected the registrant to breaching the agreement (and potentially losing the domain name). With that in mind, here is a real world example of “violation of user agreement” that could result in denying a transfer rather than for evidence of fraud. As you may know, Namecheap has a large presence in Ukraine. Recently, a customer spewed horrific propaganda towards our support team, and after being asked several times to treat our team with respect and to transfer away, he continued to escalate the rhetoric. We suspended his account, and now he cannot transfer out his domains. We canceled the registration agreement, so this falls under non-Transfer Policy reasons, but this is a time when there was a clear violation of our registration agreement that could be used to deny a transfer. For the record, we disclosed this issue to ICANN because of the gray area in “denying” the Transfer (and they did not object). Happy to discuss further, but we did want to put more than just “illegal” activities as a reason to deny transfers. I also note that “abuse” is generally defined as “DNS abuse” and not “being abusive to customer support”. Regards, Owen

On May 10, 2022, at 14:49, Mike Rodenbaugh <mike@rodenbaugh.com> wrote:

I wish to raise a further issue wrt Reco 19, allowing registrars to deny a transfer for virtually any breach of the registration agreement. Given that registrars can put just about anything they like into a registration agreement, and that they are given full discretion whether to judge whether the RNH is in some breach of it, I am concerned this is far too broad of a reason and far too much discretion for a registrar to deny a transfer.

It seems to be a fairly radical change unless we can develop some restrictive language. I think our intent was to allow greater freedom to stop transfers where there has been abuse, other than 'fraud'. And that is a laudable goal that certainly the IPC supports. So perhaps we should expand on 'fraud' but not so far as 'almost any breach of any provision of the registration agreement' (..., I am paraphrasing). We could say "fraud or other illegal or abusive behavior", or something like that?

Thanks, Mike

Mike Rodenbaugh address: 548 Market Street, Box 55819 San Francisco, CA 94104 email: mike@rodenbaugh.com <mailto:mike@rodenbaugh.com> phone: +1 (415) 738-8087

On Mon, May 9, 2022 at 2:36 AM Emily Barabas <emily.barabas@icann.org <mailto:emily.barabas@icann.org>> wrote: Dear working group members,

As a reminder, the deadline for submitting input on the draft Initial Report is 14 May 2022. Please see instructions below for additional details.

Kind regards,

Caitlin, Julie, Berry, and Emily

From: Emily Barabas <emily.barabas@icann.org <mailto:emily.barabas@icann.org>> Date: Friday, 29 April 2022 at 16:27 To: "gnso-tpr@icann.org <mailto:gnso-tpr@icann.org>" <gnso-tpr@icann.org <mailto:gnso-tpr@icann.org>> Subject: Draft Initial Report - Input Due 14 May 2022

Dear working group members,

As discussed on Tuesday’s call, staff had an action item to provide the draft Initial Report to the Working Group today for review. Please see the draft attached.

Please carefully review this draft Initial Report in coordination with the groups you represent. If you feel that there are items that need to be revised, please enter them here <https://docs.google.com/document/d/1s9xumJ1XBPdTb7kQmc5sAC2AkszvfAF0freMvnx6G18/edit>. For each item, please include:

Report version (the date listed in the header of the Initial Report draft) and applicable line numbers ( these are listed along the left margin of the document). Name and group you represent: If multiple WG members represent a group, input should be in coordination with these other members. Rationale: please provide a clear explanation for why you are proposing the revision. Specific proposed revision: Provide the language you would like to see added/removed/edited.

The deadline for submitting input is 14 May 2022. After the deadline, the working group will spend the following four working group meetings reviewing the items submitted in the input document. If your groups are unable to provide input by 14 May, feedback on the Initial Report can be provided during the public comment period.

As you review, please note that some sections of the report are highlighted:

Text highlighted in purple is relatively new and should be reviewed closely. Text highlighted in orange is still under discussion and may change. Yellow highlights are administrative in nature can be ignored.

Please do not hesitate to reach out with any questions about the review process.

Kind regards,

Caitlin, Julie, Berry, and Emily

Emily Barabas

Policy Development Support Senior Manager

Internet Corporation for Assigned Names and Numbers (ICANN)

Phone: +31 (0)6 84507976

www.icann.org [nam10.safelinks.protection.outlook.com] <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?url=http*3A*2F*2Fwww.icann.org*2F&data=05*7C01*7Crcarney*40godaddy.com*7C810c8f9ee92147643f6508da294c9280*7Cd5f1622b14a345a6b069003f8dc4851f*7C0*7C0*7C637867706113500635*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=qBOqnTAGdkl3Qzxd8PqC3fzUo*2F7kGYQZIIFIxuj47s4*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!!PtGJab4!pQ9yxEYbvsSY9NeLpnBn7A2Sax8Rfx2bpnkvXethxY_inljc5Dxm9rYeB72hJWscJHdf1SIM0g$>

_______________________________________________ GNSO-TPR mailing list GNSO-TPR@icann.org <mailto:GNSO-TPR@icann.org> https://mm.icann.org/mailman/listinfo/gnso-tpr <https://mm.icann.org/mailman/listinfo/gnso-tpr>_______________________________________________ GNSO-TPR mailing list GNSO-TPR@icann.org https://mm.icann.org/mailman/listinfo/gnso-tpr

I don’t agree with Mike’s suggestion re adding abuse and/or harm. Both abuse and harm are broad terms. I don’t want to re-open the issue, but this change is not giving registrars any more power than they have now. I believe it’s an unnecessary change and even more unnecessary to have a “May” bucket. I did say that in our group nobody agreed. Even now registrars may deny transfer because of their own registration agreement violation and ICANN as long as the issues are not within its own mandate should not/would not give an opinion or get involved. Anyhow, Owen’s clarification and suggested language had some support by NCSG though we did mention that it would have been better to be more precise and enumerate the reasons for denial of transfer. On Tue, May 10, 2022 at 7:13 PM Mike Rodenbaugh <mike@rodenbaugh.com> wrote:

Thanks Owen for the further helpful explanation. However I am not very comforted. I would like to see better guardrails in the language of the amended policy, rather than wishy-washy implementation guidance or rationale. At minimum, instead of *“violation of the Registration Agreement”, *we could say *"material breach of any material term of the Registration Agreement, as determined in the Registrar's reasonable discretion." *At least that would provide materiality and reasonableness thresholds, which should be minimum 'guardrails' in the policy.

But I would still go further because registration agreements really could say anything at all. are almost never read by the RNH, and are never relied upon nor enforceable by the acquirer of a domain from the RNH (which acquisition could be scuttled by registrar implementation of this 'reason for denial' in any given case). Again, we were talking about 'abuse' situations, which I think could encompass your example since there appears to have been abuse of registrar systems or personnel and that is a legitimate reason for suspension or termination. We could therefore go with something like this: *"material breach of any provision of the Registration Agreement, as determined in the Registrar's reasonable discretion, which provision is intended to protect internet users and/or the DNS from abuse and/or harm."*

Registrar support staff, in your example, should reasonably be deemed to be internet users that are being abused by objectionable content. I don't want to belabor your example, or any example, since the policy needs to apply in all situations to everyone. As it is currently drafted, in my view this amended policy would be ripe for misuse or abuse by registrars who would be empowered to deny any transfer for virtually any reason so long as, in their sole discretion, they find any breach of the agreement that they drafted.

I think we need to do better here.

Thanks, Mike

[image: Logo]

Mike Rodenbaugh

address:

548 Market Street <https://www.google.com/maps/search/548+Market+Street?entry=gmail&source=g>, Box 55819

San Francisco, CA 94104

email:

mike@rodenbaugh.com

phone:

+1 (415) 738-8087

On Tue, May 10, 2022 at 3:12 PM Owen Smigelski < owen.smigelski@namecheap.com> wrote:

...

Hi Mike,

This is an issue that I (and the small team) spent a lot of time trying to reconcile: the desires of registrars to be able to deny transfers for registration agreement violations (which in theory could be something other than fraud or illegal or abusive, but still very objectionable), and those of NCSG (and myself) about being able to deny a transfer for any minor breach of the registration agreement.

We compromised and decided to include this implementation guidance in the report, which will need to be included in a final report (and thus form basis of any eventual policy):

*Implementation Guidance: The intent of “violation of the Registration Agreement” is not to allow the blocking of transfers due to minor violations, but to allow action in case of substantive contravention of the Registration Agreement. *

We also provided a rationale in the notes, which will also carry forward into the final report:

*The working group noted that such abusive activities typically constitute a violation of the Registration Agreement, and therefore by including “violation of the Registration Agreement” to the reasons that the Registrar of Record MAY deny a transfer, the Policy will explicitly permit denials in these circumstances. The Implementation Guidance provides additional “guardrails” to protect against denial of transfers for minor, inadvertent violations of the Registration Agreement. The Working Group notes that Registration Agreement violations have in the past formed the basis of formal ICANN Compliance enforcement relating to domain transfer. *

I pushed hard to ensure the guardrails, because of the referenced Compliance case. I cannot provide further details (as they remain confidential), but basically agreeing to the registration agreement (and its problematic wording) would have immediately subjected the registrant to breaching the agreement (and potentially losing the domain name).

With that in mind, here is a real world example of “violation of user agreement” that could result in denying a transfer rather than for evidence of fraud. As you may know, Namecheap has a large presence in Ukraine. Recently, a customer spewed horrific propaganda towards our support team, and after being asked several times to treat our team with respect and to transfer away, he continued to escalate the rhetoric. We suspended his account, and now he cannot transfer out his domains. We canceled the registration agreement, so this falls under non-Transfer Policy reasons, but this is a time when there was a clear violation of our registration agreement that could be used to deny a transfer. For the record, we disclosed this issue to ICANN because of the gray area in “denying” the Transfer (and they did not object).

Happy to discuss further, but we did want to put more than just “illegal” activities as a reason to deny transfers. I also note that “abuse” is generally defined as “DNS abuse” and not “being abusive to customer support”.

Regards,

Owen

On May 10, 2022, at 14:49, Mike Rodenbaugh <mike@rodenbaugh.com> wrote:

I wish to raise a further issue wrt Reco 19, allowing registrars to deny a transfer for virtually any breach of the registration agreement. Given that registrars can put just about anything they like into a registration agreement, and that they are given full discretion whether to judge whether the RNH is in some breach of it, I am concerned this is far too broad of a reason and far too much discretion for a registrar to deny a transfer.

It seems to be a fairly radical change unless we can develop some restrictive language. I think our intent was to allow greater freedom to stop transfers where there has been abuse, other than 'fraud'. And that is a laudable goal that certainly the IPC supports. So perhaps we should expand on 'fraud' but not so far as 'almost any breach of any provision of the registration agreement' (..., I am paraphrasing). We could say "fraud or other illegal or abusive behavior", or something like that?

Thanks, Mike

[image: Logo] Mike Rodenbaugh address: 548 Market Street <https://www.google.com/maps/search/548+Market+Street?entry=gmail&source=g>, Box 55819 San Francisco, CA 94104 email: mike@rodenbaugh.com phone: +1 (415) 738-8087

On Mon, May 9, 2022 at 2:36 AM Emily Barabas <emily.barabas@icann.org> wrote:

...

Dear working group members,

As a reminder, the *deadline for submitting input on the draft Initial Report is 14 May 2022. *Please see instructions below for additional details.

Kind regards,

Caitlin, Julie, Berry, and Emily

*From: *Emily Barabas <emily.barabas@icann.org> *Date: *Friday, 29 April 2022 at 16:27 *To: *"gnso-tpr@icann.org" <gnso-tpr@icann.org> *Subject: *Draft Initial Report - Input Due 14 May 2022

Dear working group members,

As discussed on Tuesday’s call, staff had an action item to provide the draft Initial Report to the Working Group today for review. Please see the draft attached.

Please carefully review this draft Initial Report in coordination with the groups you represent. If you feel that there are items that need to be revised, please enter them here <https://docs.google.com/document/d/1s9xumJ1XBPdTb7kQmc5sAC2AkszvfAF0freMvnx6G18/edit>. For each item, please include:

- Report version (the date listed in the header of the Initial Report draft) and applicable line numbers ( these are listed along the left margin of the document). - Name and group you represent: If multiple WG members represent a group, input should be in coordination with these other members. - Rationale: please provide a clear explanation for why you are proposing the revision. - Specific proposed revision: Provide the language you would like to see added/removed/edited.

*The deadline for submitting input is 14 May 2022.* After the deadline, the working group will spend the following four working group meetings reviewing the items submitted in the input document. If your groups are unable to provide input by 14 May, feedback on the Initial Report can be provided during the public comment period.

As you review, please note that some sections of the report are highlighted:

- Text highlighted in purple is relatively new and should be reviewed closely. - Text highlighted in orange is still under discussion and may change. - Yellow highlights are administrative in nature can be ignored.

Please do not hesitate to reach out with any questions about the review process.

Kind regards,

Caitlin, Julie, Berry, and Emily

Emily Barabas

Policy Development Support Senior Manager

Internet Corporation for Assigned Names and Numbers (ICANN)

Phone: +31 (0)6 84507976

www.icann.org [nam10.safelinks.protection.outlook.com] <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?url=http*3A*2F*2Fwww.icann.org*2F&data=05*7C01*7Crcarney*40godaddy.com*7C810c8f9ee92147643f6508da294c9280*7Cd5f1622b14a345a6b069003f8dc4851f*7C0*7C0*7C637867706113500635*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=qBOqnTAGdkl3Qzxd8PqC3fzUo*2F7kGYQZIIFIxuj47s4*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!!PtGJab4!pQ9yxEYbvsSY9NeLpnBn7A2Sax8Rfx2bpnkvXethxY_inljc5Dxm9rYeB72hJWscJHdf1SIM0g$>

_______________________________________________ GNSO-TPR mailing list GNSO-TPR@icann.org https://mm.icann.org/mailman/listinfo/gnso-tpr

_______________________________________________ GNSO-TPR mailing list GNSO-TPR@icann.org https://mm.icann.org/mailman/listinfo/gnso-tpr

_______________________________________________ GNSO-TPR mailing list GNSO-TPR@icann.org https://mm.icann.org/mailman/listinfo/gnso-tpr

-- Farzaneh