[gnso-gac-closed-generics] Closed Generics Updates - 14 April 2023

[Nigel Hickson]

Greg and colleagues

Good morning and thanks for this Greg which I found really useful.

What you say seems eminently sensible; ICANN must be able to enforce such
provisions and thus be pro-acrive where necessary in seeking views of the
appropriate authorities.

Best

Nigel


On Wed, 19 Apr 2023, 06:41 Greg Shatan [NARALO], <gregshatanalac at gmail.com>
wrote:

> All,
>
> Jeff has proposed the following:
>
> In other words, it would not be for ICANN to determine what is
> “anti-competitive”, but rather such determinations would be made by courts
> of national jurisdiction.  If they found a violation of law, then ICANN
> would have to ensure the registry takes remedial actions.  ICANN Compliance
> should never be in the position of having to determine whether an action is
> ”anti-competitive” in any jurisdiction.
>
> Philippe wrote something similar:
>
> As I observed during our last call, I think asking the applicant “to
> commit” is the right thing to do, and I don’t think this can call for more
> than ticking a box or a “Yes we commit.” sort of response: I don’t expect a
> panel/committee or even compliance to be in a position to determine whether
> a particular behaviour is anticompetitive or not, as authority on the
> matter lies with national/regional competition authorities/agencies.
>
>
>
> I’m not saying that a closed generics may not lead to an anticompetitive
> behaviour (I don’t know) but from a practical standpoint, I can only expect
> “ICANN” to rely on those authorities to decide/rule on whether that is the
> case, and act accordingly in the event, based on the fact that the
> applicant didn’t live up to their “commitment”.
>
> This runs counter to the concept of enforceability and to the reality of
> how contracts are enforced.  It is utterly common for contracts to contain
> provisions that obligate a party to comply with (and/or not to violate)
> specified laws, and more generally to comply with applicable law.  In my
> experience and observation, a contracting party will just about always
> determine for itself (through the advice of appropriate counsel) whether
> the other party is breaching one of these provisions and will take
> appropriate action (notice of breach, possible suspension or termination
> for cause, notice and demand for "cure"/remediation, etc. -- including
> "softer" or more nuanced approaches).  If the parties cannot resolve the
> issue between themselves, they may end up in court, but that is only a
> small percentage of the time.  Even then, it is much more common for the
> parties to settle rather than litigate to a verdict.
>
> The only times I have observed a party wait until there's a court verdict
> or regulatory finding is when the contract provision specifically and
> expressly states that that is the threshold for breach.
>
> To state the obvious, courts (in most jurisdictions) cannot initiate a
> case on their own initiative -- there must be a plaintiff (either a private
> party (in civil litigation) or the state (which can be civil or criminal))
> who initiates the case (by filing a complaint or other similar action).
>
> These proposals would utterly tie the hands of ICANN in contract
> compliance and enforcement.  ICANN, like any other party to a contract,
> must be free to determine for itself when a contract is being breached and
> to take appropriate action.  It would be far too extreme to require ICANN
> to go straight to a lawsuit when it believes that a contractual obligation
> to comply with laws is being violated.  It would be even more extreme to
> prohibit ICANN from taking any action and require it to wait for a third
> party to bring a case or a government to bring a case or initiate an
> investigation and secure a verdict or make a regulatory determination
> before ICANN can take appropriate action.  That would take us massively
> backward on concepts of contractual compliance and enforcement that have
> gradually improved over time.
>
> Of course, there could be times when cases are brought and verdicts are
> secured that find behavior that violates contracts with ICANN, and ICANN
> will of course be able to react and take appropriate enforcement action
> regarding contracts.  But those times frankly are edge cases. That cannot
> be our standard for any type of contractual commitment, including (but not
> limited to), commitments relating to closed generics.
>
> Best regards,
>
> Greg
>
>
>
>
> On Tue, Apr 18, 2023 at 4:37 PM <philippe.fouquart at orange.com> wrote:
>
>> Thanks John. Your suggestion works for me too for the reasons given in my
>> previous post.
>> Best,
>> Philippe
>>
>>
>> Le 18 avr. 2023 22:04, John McElwaine <john.mcelwaine at nelsonmullins.com>
>> a écrit :
>>
>> Jeff,
>>
>>
>>
>> That was my intent.
>>
>>
>>
>> John
>>
>>
>>
>> *From:* Jeff Neuman <jeff at jjnsolutions.com>
>> *Sent:* Tuesday, April 18, 2023 4:02 PM
>> *To:* John McElwaine <john.mcelwaine at nelsonmullins.com>; Melissa Peters
>> Allgood <melissa.allgood at icann.org>; gnso-gac-closed-generics at icann.org
>> *Subject:* RE: [gnso-gac-closed-generics] Closed Generics Updates - 14
>> April 2023
>>
>>
>>
>> Thanks John.  I can live with your number 2 *If* all of those acts are
>> predicated in violation of national laws.
>>
>>
>>
>> In other words, if I were to rewrite your #2 as I am ok with it being
>> interpreted, it would be:
>>
>>
>>
>> .            For “non anti-competitive behaviour”, applicants must commit
>> that its use of this closed generic gTLD will not be used to violate
>> applicable national laws prohibiting unfair methods of competition.  This
>> includes, but is not limited to, , such as collusion, restraints of
>> trade that prohibit third parties from supplying or offering to supply
>> goods or services, or otherwise monopolistically controlling, limiting, or
>> restricting the supply of goods or services.
>>
>>
>>
>> In other words, it would not be for ICANN to determine what is
>> “anti-competitive”, but rather such determinations would be made by courts
>> of national jurisdiction.  If they found a violation of law, then ICANN
>> would have to ensure the registry takes remedial actions.  ICANN Compliance
>> should never be in the position of having to determine whether an action is
>> ”anti-competitive” in any jurisdiction.
>>
>>
>>
>> Hopefully this is what you meant John.  If so, I can support.  If not, it
>> is a red line for me to have ICANN compliance act as a substitute for
>> regulator of national laws.
>>
>>
>>
>> Sincerely,
>>
>>
>>
>> Jeff
>>
>>
>>
>>
>>
>>
>>
>> Jeffrey J. Neuman
>>
>> Founder & CEO
>>
>> JJN Solutions, LLC
>>
>> p: +1.202.549.5079
>>
>> E: jeff at jjnsolutions.com
>>
>> http://jjnsolutions.com
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__jjnsolutions.com&d=DwMGaQ&c=qmi9WrYRGQEDDOxOwKrAjW7mWovpzN_EKyRbeK_zbP0&r=Kepk-9GEB6JgOj0vUGl8c0hdrRM7FW-8Is-VAQU1VAm5U0rBXiZs3BfB3GfKU2uR&m=MeoIhLexdpwao9NQLMENEawFWz_0kTVclFlB0Xk_SAtHPNGbTYinOoLoeRir7-ho&s=ez0rB5lxV3bl0kZ1GOvz_DjYm-vAme9Rusom0REQMCk&e=>
>>
>>
>>
>>
>>
>> *From:* gnso-gac-closed-generics <
>> gnso-gac-closed-generics-bounces at icann.org> *On Behalf Of *John McElwaine
>> *Sent:* Tuesday, April 18, 2023 11:59 AM
>> *To:* Melissa Peters Allgood <melissa.allgood at icann.org>;
>> gnso-gac-closed-generics at icann.org
>> *Subject:* Re: [gnso-gac-closed-generics] Closed Generics Updates - 14
>> April 2023
>>
>>
>>
>> With respect “representativeness”, I must respectfully state that the
>> following is a redline for me:
>>
>>
>>
>>    1. *For “representativeness”, applicants must demonstrate that the
>>    applicant represents all or a significant part of the businesses (or has
>>    their agreement) in the industry or grouping related to the closed generic
>>    term.*
>>
>>
>>
>> The revisions would *only* allow for a closed generic applicant that was
>> an international trade association of businesses.  This is far afield from
>> what we have discussed and would fall into the category of an impermissible
>> Policy determination.
>>
>>
>>
>> I agree with the concept of  “Non Anti-Competitiveness” as a part of the
>> Framework process as a part of the delegation section, which is Section
>> IV.  However, we are discussing this mostly in a double-negative way.
>> Moreover, this is an area of law that I fear we are trying to define and
>> which is outside of our knowledge.  I prefer something like Proposed
>> Alternative #1, which I would suggest is revised as follows:
>>
>>
>>
>> 2.            For “non anti-competitive behaviour”, applicants must
>> commit that its use of this closed generic gTLD will not be used to violate
>> national laws prohibiting unfair methods of competition, such as collusion,
>> restraints of trade that prohibit third parties from supplying or offering
>> to supply goods or services, or otherwise monopolistically controlling,
>> limiting, or restricting the supply of goods or services
>>
>>
>>
>> Thanks,
>>
>>
>>
>> John
>>
>>
>>
>>
>>
>>
>>
>> *From:* gnso-gac-closed-generics <
>> gnso-gac-closed-generics-bounces at icann.org> *On Behalf Of *Melissa
>> Peters Allgood
>> *Sent:* Friday, April 14, 2023 2:34 PM
>> *To:* gnso-gac-closed-generics at icann.org
>> *Subject:* [gnso-gac-closed-generics] Closed Generics Updates - 14 April
>> 2023
>>
>>
>>
>> *◄External Email►* - From: gnso-gac-closed-generics-bounces at icann.org
>>
>>
>>
>> Hi all –
>>
>>
>>
>> I want to share a bit of the work that staff has done to support your
>> efforts and provide more detail about the approach to our upcoming calls.
>>
>>
>>
>> *Discussion Draft v2.1
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1wtLVcyWhyrCaYl1iqlAncaIyrqpS-2D-2D0aPCTjpwMue7I_edit&d=DwMGaQ&c=qmi9WrYRGQEDDOxOwKrAjW7mWovpzN_EKyRbeK_zbP0&r=Kepk-9GEB6JgOj0vUGl8c0hdrRM7FW-8Is-VAQU1VAm5U0rBXiZs3BfB3GfKU2uR&m=ODO8endu2yFS9Q7WIZvDyDo1jWyvQo0fVRf64r8ZyBJHmS1kTm2DEU42C8rV4FGM&s=n6Zv8I5X6-mQu2qIZs8CpuYTk5kqq3ZsvNMfiqiSDUM&e=>*
>>
>> We will continue to work our way through all your inputs into this
>> document. It has been cleaned up slightly, hence the v2.1, but nothing of
>> substance has been altered. We will move through this document in the
>> following manner:
>>
>>    - Section III.  Applying for a Closed Generic gTLD
>>    - Section IV. Evaluating a Closed Generic gTLD Application
>>    - Section V. Contracting & Post-Delegation Review
>>    - Definitions
>>    - Policy questions and possible implementation questions based on
>>    group discussions to date
>>       - I don’t anticipate getting into the substance of these and will
>>       simply ask if the areas detailed properly encapsulate other conversations
>>       had by this group
>>
>>
>>
>> In comments, staff have identified possible areas of duplication in
>> upcoming points under discussion. When such areas arise, I will ask for the
>> temperature of the room on the duplication issue before possibly moving
>> onto the substance of the framework element.
>>
>>
>>
>> *Closed Generics Framework v3
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1u0Nb9-5FCJ-2D6R-5FZF4bt9wbkzxLhMKu64aKY-5FvzS3QixgQ_edit&d=DwMGaQ&c=qmi9WrYRGQEDDOxOwKrAjW7mWovpzN_EKyRbeK_zbP0&r=Kepk-9GEB6JgOj0vUGl8c0hdrRM7FW-8Is-VAQU1VAm5U0rBXiZs3BfB3GfKU2uR&m=ODO8endu2yFS9Q7WIZvDyDo1jWyvQo0fVRf64r8ZyBJHmS1kTm2DEU42C8rV4FGM&s=k27Asp9yNGvBNSgyJY2Pi8f1F7M5gBtFQCRbjkgfgm0&e=>*
>>
>> This is a clean copy of framework elements from Discussion Draft v2.1
>> where the group has demonstrated broad agreement. This document will
>> continue to evolve as you work through the remaining sections of Discussion
>> Draft v2.1. *Please keep this document clean*. We will consider this
>> document as a whole after we complete the remaining work found in
>> Discussion Draft v2.1.
>>
>>
>>
>> *Proposed Edits to Representativeness or Non Anti-Competitiveness*
>>
>> Sophie has shared proposed edits to this element on the mailing list.
>> Please respond on the mailing list if:
>>
>>    1. You disagree *and* this a red line for you
>>    2. You wish to state a preference between the options presented
>>
>> Staff will incorporate your feedback on this element into Discussion
>> Draft v2.1.
>>
>>
>>
>> *Upcoming Discussions*
>>
>> As we continue to work through Discussion Draft v2.1, I’d remind you that
>> this is *not *the time to rehash previous positions. We all understand
>> that many elements under discussion may not be the preference of a given
>> individual while also not rising to the level of personal red line.
>> Accordingly, *I ask you limit interventions to clarifying questions
>> and/or indications that the text under discussion is a personal red line.*
>>
>>
>>
>> Finally, at this point in the work I ask you focus your energy on the
>> spirit and intention of each framework element under discussion rather than
>> details of the text. I recognize this is far easier said than done, but I
>> ask we all try.
>>
>>
>>
>> As always, my sincere thanks for your continued hard work. We are getting
>> there!
>>
>>
>>
>> Wishing you all a lovely weekend,
>>
>> Melissa
>>
>> *Confidentiality Notice*
>> This message is intended exclusively for the individual or entity to
>> which it is addressed. This communication may contain information that is
>> proprietary, privileged, confidential or otherwise legally exempt from
>> disclosure. If you are not the named addressee, you are not authorized to
>> read, print, retain, copy or disseminate this message or any part of it. If
>> you have received this message in error, please notify the sender
>> immediately either by phone (800-237-2000) or reply to this e-mail and
>> delete all copies of this message.
>>
>>
>> _________________________________________________________________________________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.
>>
>> _______________________________________________
>> gnso-gac-closed-generics mailing list
>> gnso-gac-closed-generics at icann.org
>> https://mm.icann.org/mailman/listinfo/gnso-gac-closed-generics
>>
>> _______________________________________________
>> 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 (https://www.icann.org/privacy/policy) and
>> the website Terms of Service (https://www.icann.org/privacy/tos). 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.
>
>
>
> --
> *Greg Shatan*
> *Chair, NARALO*
> _______________________________________________
> gnso-gac-closed-generics mailing list
> gnso-gac-closed-generics at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-gac-closed-generics
>
> _______________________________________________
> 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 (https://www.icann.org/privacy/policy) and
> the website Terms of Service (https://www.icann.org/privacy/tos). 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-gac-closed-generics/attachments/20230419/003df24c/attachment-0001.html>