[Gnso-newgtld-wg] PIC/RVC Enforcement

Aikman-Scalese, Anne AAikman at lrrc.com
Thu Dec 17 19:35:24 UTC 2020

Thanks Alan.  I agree with you that there should be third party dispute resolution. For example, in a UDRP proceeding, to which registries are bound, the dispute provider has to make a determination of bad faith on the part of the defendant registrant.  This is not a content determination by ICANN and no one is asking ICANN to make that judgment.  The UDRP process and the decision are still enforceable and ICANN doesn't have to be involved in the determination.

I don't know what we would say about how ICANN should amend ByLaws because I don't think anyone is on board with ICANN making content judgments.  That is why the third party dispute resolution provider for non-mandatory PICs and RVCs is the right solution.

From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces at icann.org> On Behalf Of Alan Greenberg
Sent: Wednesday, December 16, 2020 9:25 PM
To: New gTLD SubPro <gnso-newgtld-wg at icann.org>
Subject: [Gnso-newgtld-wg] PIC/RVC Enforcement

Prior to the last meeting, I sent a message giving my reasons for not being comfortable with ICANN's ability to enforce PIC/RVCs and particularly those that may involve content.

It was suggested that I review the current redline draft to see if it does not address my concerns.

I have done so, and I note that it does not address my concerns and in fact gave rise to a related issue that I had not previously noticed.

1. I still have concern that there is nothing in the recommendations that forces a registry to select a reputable panel to address potential violations of PICs/RVCs, and there is nothing that requires it to pay for such services. The recommendations rely solely on the PICDRP, a process that can only be initiated if the party filing the DRP can show material harm from the violation.

It must not be necessary to show harm to ensure that contracts can be adhered to. Moreover, there should not be a substantive cost for ensuring that such contracts are honored. If an body external to ICANN must be used to address contract compliance, such a requirement must be explcitly required in the contract and we cannot rely on implementation to ensure that.

2. I am not at all convinced that the statement (a) on page 45 is correct: "To the extent that existing PICs are used as PICs (or RVCs) in subsequent rounds, these are specifically ?grandfathered? into the current Bylaws mission."

I presume that this is based on a reading of Bylaws clause 1.1(d)(ii)(A)(2) "any registry agreement or registrar accreditation agreement not encompassed by (1) above to the extent its terms do not vary materially from the form of registry agreement or registrar accreditation agreement that existed on 1 October 2016"

Saying that a contract that is "does not vary materially" is not the same as saying you can extract tidbits from it and those tidbits remain valid.

Even if my reading is incorrect, it demonstrates that we are making many assumptions leading to the belief that PIC/RVCs will be enforceable. All of those assumptions may prove to be valid, and that is just fine. But *IF* they are not all valid, then the entire concept of enforceable commitments collapses.

We must make an explicit recommendation saying that if it turns out that there is a problem enforcing PIC/RVC, the Board must take action to remedy the problem and such action might need to include Bylaw amendment.



This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. ?2510-2521.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20201217/6041988f/attachment.html>

More information about the Gnso-newgtld-wg mailing list