<html><head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></head>

<body>

Jeff, <br><br>

Sorry for the delay in replying to this message.<br><br>

I am not at all sure I agree with some of you "principles", but

the specific details are not relevant to this message.<br><br>

However, the fact that I don't fully agree, and that you have used the

expression "I/we believe/think" six times in this messages

clearly implies some level of uncertainty regarding whether what you

believe (or hope?) is how all of this will play out. Moreover, in at

least one part of the scenario, you state as a fact something that may

not turn out to be the case (see 1st remedy).<br><br>

There are two remedies that can address these issues:<br><br>

1. There needs to be an enforceable contractual provision that in the

case of PIC/RVC disputes, the Registry must contract with an ICANN

identified dispute resolution provider (or one of a pre-selected group of

providers). And obviously pay for the process. If the Ry can choose the

provider, or simply refuse to do it, the whole thing becomes a sham. I

also note that there may be costs associated with setting up the dispute

resolution process and ICANN would have to bear that.<br><br>

2. As noted above, there are a LOT of assumptions, beliefs and hopes in

all of this. If any of these prove false, the house of cards collapses

and we may be left in the laughable position of ICANN signing contracts

which they know will not be enforceable. In the real world, there will

always be cases where some contractual terms end up being unenforceable,

but it makes no sense at all to have that knowledge before signing and

proceed. We must include a recommendation that,  should it turn out

that the PIC/RVCs are not fully enforceable, the ICANN Board must take

appropriate action to remedy the situation and ensure enforceability,

even if that action requires Bylaw amendment.<br><br>

Alan<br><br>

<br><br>

At 2020-12-09 03:22 PM, Jeff Neuman wrote:<br><br>

<blockquote type="cite" class="cite" cite="">All,<br><br>

I know there have been a lot of e-mails on this subject in the last week

or so.  I wanted to give you some perspectives that we discussed at

the leadership level to see if we can find some common themes and then we

can see if any language in our report needs to change (which I am not

convinced there will need to be substantial changes).  This is my

(Jeff Neuman) summary to move the discussion along.<br><br>

So, here is where I think we are on principles:<br><br>

<ol>

<li><u>Existing PICs used as PICs in New Registry</u> Agreements: 

We believe that the existing PICs – worded substantially the same as they

were in 2012 – are ok under ICANNā€™s Bylaws as they are sspecifically

ā€œgrandfatheredā€ in.

</ol><br>

<ol>

<li><u>Domain Name Eligibility Rules</u>:  We all seem to be on the

same page that eligibility rules for the registration/renewal (but not

necessarily usage) can be included in PICs/RVCs under ICANN Bylaws.

</ol><br>

<ol>

<li><u>Voluntary Registry Commitments</u>:

</ol><br>

<ol>

<ol>

<li><u>Commitments made by Registries without ICANN Enforcement</u>

</ol>

</ol><br>

i.      Registries and Registrars have reserved

their rights to take down domain names for phishing, pharming, malware,

and other forms of domain name abuse.  With respect to Registries,

some have built these directly in as PICs while others have just built

this into their Registry-Registrar Agreements (and some do both). 

These types of PICs / RVCs do not seem to present any issue under the

ICANN Bylaws (in our view).  <br><br>

 <br><br>

ii.      We also believe that it is fairly

common for registries to have policies that allow them to take down any

domains used in connection with illegal activity, child exploitation,

fraud, the sale of illegal pharmaceuticals, etc.  <br><br>

 <br><br>

iii.      Because these do not require ICANN

enforcement, we see no reason how or why this would present an ICANN

Bylaw issues.  Conversely, we see no reason why we (through a PDP)

would have any ability to restrict the ability of a registry to impose

these types of commitments on their registrants (through registrars or

directly).  So while we appreciate Kathyā€™s concern about a

Registryā€™s ability to take down domain names, we do not believe that we

are in a position to either require registries to take down names based

on content or to prohibit them from doing so either.  Both could be

considered forms of regulation (imposing rules on what a registry has to

do or what it may not do).<br><br>

 <br><br>

iv.      <u>Real Example Today</u>. 

.gay.  The Registry Operator for .gay (Top Level Design) want to

have a safe space for the LGBTQ community.  That community, as most

of you know, has historically been the subject of hate speech, violence,

bullying, etc.  Having a safe space for the gay community according

to the registry is its differentiator and is absolutely necessary. 

It has an incredibly strict Rights Protections Policy

(<a href="https://www.ohhey.gay/gay-cares">

https://www.ohhey.gay/gay-cares</a>) that prevents Registrants from (i)

inciting or promoting violence against others, (ii) Bullying, engaging in

cyber bullying or inciting others to bully, (iii) Harassing, or

encouraging others to harass or harm others, (iv) Stalking, (v) Abusive

intent to cause fear or threaten violence, (vi) Hate Speech, (vii) Or

activity intended to organize, coordinate, or otherwise enable one of the

above.  It also reserves the right to take down any sites that do

any of the above at its sole discretion.  <br><br>

<ol>

<ol>

<li><u>Commitments made by Registries that may require ICANN Enforcement

in some capacity</u>

</ol>

</ol><br>

 <br><br>

Some Registries will want to make voluntary commitments in response to

public comments, Government early warnings, objections, GAC Advice, etc.

We do not see an issue with having these commitments reflected in

Registry Agreements even if they fall outside of ICANNā€™s core mission

IF in the case where the commitment does not fall within ICANNā€™s

mission, neither ICANN itself nor any third party under ICANNā€™s control

is involved in the decision as to whether the commitment itself has been

violated.  Where an independent third party finds a violation of the

commitment, ICANN should be able to rely on that third party decision and

enforce a pre-arranged contractual remedy, which could include sanctions

and/or termination of the Registry Agreement.<br><br>

 <br><br>

<u>Examples / Use Cases:<br>

</u><br>

<ol>

<li>If an Applicant applies for the TLD

ā€œ.dictionarywordthatisalsobrandxā€ and Brand X objects to the

application.  Applicant agrees with Brand X that it will not use the

TLD in an infringing manner to Brand X.   In exchange for that

Agreement, Brand X agrees to drop its Objection IF the Applicant agrees

to put this commitment into its Registry Agreement in the form of an

RVC.

<ol>

<li>As a PDP Working Group we have often said that it is our preference

for disputes, objections, etc. to be worked out between the parties where

this is possible.  This is in line with our desire to see future

expansion of the TLD space and encourage innovation and competition.

<li>As a result, this type of private resolution should be encouraged.

<li>The question, however, is whether ICANN could enforce this

commitment.  

<li>After our discussions with the ICANN Board liaisons and the comments

we received by the community, the real concern was that ICANN did not

believe it could be put in a decision to make these types of decisions

(namely in this case whether Applicantā€™s use of the TLD violates its

commitment to Brand X).

<li>If the Applicant and Brand X agree that any disputes involving their

ā€œsettlementā€ are resolved by an independent third party (not ICANN)

and the costs are borne by the parties (as opposed to ICANN), this should

not present a problem.

<li>If ICANN implements the decision by the independent third party

(which the Applicant agreed in its Registry Agreement to allow ICANN to

do), this too should not present a Bylaws issue.

<li>The key point here is that ICANN itself is not imposing the

restrictions on the Applicant and therefore should not be violating its

own Bylaws.

</ol>

</ol><br>

<ol>

<li>What if an Applicant applies for .ideaexchange?  The Applicant

wants to run the TLD as a place where registrants can put their open

source ideas on the Internet and allow others to use their ideas in

connection with whatever they want.  Comments are filed by

businesses, governments, intellectual property owners and others

concerned that this will be a space where users will exchange

intellectual property that they do not own.  Lets also assume that

the Independent Objector files an objection as well.  Assume

Applicant never intended that and agrees that it will have a policy

whereby Registrants agree that they will not use the TLD to distribute

any intellectual property that is not owned by them.  And the

Applicant also reserves the right to take down any names that use the TLD

in violation of this policy.  To resolve the comments filed by

governments, businesses, etc., the Applicant voluntarily agrees to have

an RVC that states this policy and the takedown processes.  Each of

the commenters and the Independent Objector agree that this would settle

the matter and if documented in the Registry Agreement, they would drop

their challenges.

<ol>

<li>We believe that having these comments resolved in an amicable manner

should be encouraged.

<li>Because this new policy has to be documented somewhere, the only real

place it can be documented is as an RVC in the Registry Agreement.

<li>ICANN should not be the arbiter of whether there is a violation of

this policy. This would certainly arguably be beyond its mission.

<li>However, if the arbiter of any disputes is an independent third

party, not paid by ICANN, etc., then this would seemingly be ok even if

it is agreed by the Applicant to follow the third party decision and to

allow ICANN to impose the appropriate remedy.

</ol>

</ol><br>

 <br><br>

<b>Bottom Line:  I believe that so long as ICANN is not the ultimate

decision maker in whether a policy that may arguably be outside of its

mission, there should be no issues with having new PICs and/or Registry

Voluntary Commitments.  If this indeed is the case, then we would

just need to add a recommendation that (a) independent third parties must

be used to resolved any potential violations of the PICs / RVCs, and (b)

Applicants would need to agree in a Registry Agreement to be bound by the

decision of the third party and to allow ICANN to impose sanctions /

penalties.  <br>

</b><br>

 <br><br>

<img src="cid:.0" width="178" height="81" alt="[]"><br><br>

Jeffrey J. Neuman<br><br>

Founder & CEO<br><br>

JJN Solutions, LLC<br><br>

p: +1.202.549.5079<br><br>

E:

<a href="mailto:jeff@jjnsolutions.com">jeff@jjnsolutions.com</a><br><br>

<a href="http://jjnsolutions.com/" eudora="autourl">

http://jjnsolutions.com</a><br><br>

 <br><br>

 <br><br>

<br>

_______________________________________________<br>

Gnso-newgtld-wg mailing list<br>

Gnso-newgtld-wg@icann.org<br>

<a href="https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg" eudora="autourl">

https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg</a><br>

_______________________________________________<br>

By submitting your personal data, you consent to the processing of your

personal data for purposes of subscribing to this mailing list accordance

with the ICANN Privacy Policy

(<a href="https://www.icann.org/privacy/policy" eudora="autourl">

https://www.icann.org/privacy/policy</a>) and the website Terms of

Service

(<a href="https://www.icann.org/privacy/tos" eudora="autourl">

https://www.icann.org/privacy/tos</a>). You can visit the Mailman link

above to change your membership status or configuration, including

unsubscribing, setting digest-style delivery or disabling delivery

altogether (e.g., for a vacation), and so on.</blockquote></body>

</html>