[GNSO-TPR] Reminder: Draft Initial Report - Input Due 14 May 2022

Tue May 10 22:12:17 UTC 2022

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 at 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 at rodenbaugh.com <mailto:mike at rodenbaugh.com>
> phone:
> +1 (415) 738-8087
> 
> 
> On Mon, May 9, 2022 at 2:36 AM Emily Barabas <emily.barabas at icann.org <mailto:emily.barabas at 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 at icann.org <mailto:emily.barabas at icann.org>>
> Date: Friday, 29 April 2022 at 16:27
> To: "gnso-tpr at icann.org <mailto:gnso-tpr at icann.org>" <gnso-tpr at icann.org <mailto:gnso-tpr at 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 at icann.org <mailto:GNSO-TPR at icann.org>
> https://mm.icann.org/mailman/listinfo/gnso-tpr <https://mm.icann.org/mailman/listinfo/gnso-tpr>_______________________________________________
> GNSO-TPR mailing list
> GNSO-TPR at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-tpr

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20220510/3d24896e/attachment-0001.html>