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

Tue May 10 23:12:17 UTC 2022

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, Box 55819

San Francisco, CA 94104

email:

mike at rodenbaugh.com

phone:

+1 (415) 738-8087

On Tue, May 10, 2022 at 3:12 PM Owen Smigelski <owen.smigelski at 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 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
>
> [image: Logo]
> Mike Rodenbaugh
> address:
> 548 Market Street, Box 55819
> San Francisco, CA 94104
> email:
> 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>
> 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>
>> *Date: *Friday, 29 April 2022 at 16:27
>> *To: *"gnso-tpr at icann.org" <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
>> 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/00418f74/attachment-0001.html>