[Gnso-newgtld-wg] PIC/RVC Enforcement

Thu Dec 17 16:14:11 UTC 2020

Hi Jeff, I think we are closing in on agreement.  More below, and I
preface my comments with => and add a question. 

----- Original Message -----
From: "Jeff Neuman" 
To:"Alan Greenberg" , "New gTLD SubPro" 
Cc:
Sent:Thu, 17 Dec 2020 14:13:46 +0000
Subject:Re: [Gnso-newgtld-wg] PIC/RVC Enforcement

	Thanks Alan. 

	A couple of comments.

	* The Board asked us to provide our view as a Working Group on the
PICs on a number of items, including enforceability.  And that is
what we state in the report; namely, that it is enforceable.  If the
Board disagrees, it could either (a) send it back, or (b) implement
our view through an amendment through a bylaw amendment.  This can be
done at the IRT stage.  We are literally on Content Freeze day and we
are not comfortable adding a recommendation that the bylaws be
changed.

	=> Jeff, I have to agree with you on this one. We cannot have
privately-inserted provisions (RVCs) doing the forcing ICANN to change
its Bylaws. The 2016 Bylaws are our (ICANN's) commitment to the US
Government (in exchange for ICANN's independence) and to the world. 
And the Attorney Generals are watching closely now. Agree that
privately-inserted terms cannot change or superseded ICANN's Bylaws. 

	* The statement “To the extent that existing PICs are used as PICs
(or RVCs) in subsequent rounds, these are specifically
grandfathered…..” does refer to the clause references.  The
statement does not say “tidbits of the PICs” or “concepts of the
PICs”, etc.  It literally states that to the extent that existing
PICs are used.  The plain meaning of that text certainly means the
PICs as they are currently written.  That said, clarifying it to
state (in bracketed text):

	* 

	* “_To the extent that existing PICs are used as PICs (or RVCs) in
subsequent rounds [without material variation], these are specifically
grandfathered into the current Bylaws mission.”_

	 ==>  _Can you give us the section and page for this change in the
Final Report? _Tx!

	* A dispute panel needs to be approved by the relevant parties.  So,
if there is a PIC as a result of a settlement between 2 parties, then
the 2 parties would “prearrange” for a dispute provider.  We
should not assume that those parties will (or will not) select a
reputable party.

	==>  I think I agree with this one too.  _Ditto to question
above. _ 

	* For PICs that rely on ICANN to “enforce”; namely those that a
Registry makes to satisfy GAC Advice, or an ALAC Objection, etc., then
it will be up to ICANN and the registry to pick a dispute provider and
put that into the Agreement.  Again, we should not be assuming that
the registry and ICANN will pick anything other than a reputable
provider.

	 ==> I think I agree on this one too. 

	I hope that makes sense.

	==>  Best, Kathy

	Jeffrey J. Neuman

	Founder & CEO

	JJN Solutions, LLC

	p: +1.202.549.5079

	E: jeff at jjnsolutions.com [1]

	http://jjnsolutions.com

	FROM: Gnso-newgtld-wg  ON BEHALF OF Alan Greenberg
SENT: Wednesday, December 16, 2020 11:25 PM
TO: New gTLD SubPro 
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.

Alan

Links:
------
[1] mailto:jeff at jjnsolutions.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20201217/a67b681b/attachment-0001.html>