[Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 09 April 2000 UTC

Julie Hedlund julie.hedlund at icann.org
Thu Apr 9 21:49:31 UTC 2020


Dear Working Group members,

Please see below the notes from the meeting on 09 April at 2000 UTC. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2020-04-09+New+gTLD+Subsequent+Procedures+PDP.

Kind regards,
Julie

Notes and Action Items:

 Actions:

2.8.1 Objections [All Sub-Sections Except GAC Early Warning and GAC Advice - Not Yet Completed]
c. New issues raised in deliberations since publication of the Initial Report, if applicable.
String Confusion Objection:
ACTION ITEM: Make sure there is time in the Work Plan for the WG to discuss the GAC’s Advice in Category 1 and develop a response to the GAC’s Advice and how to address highly regulated or sensitive strings.  Note that the WG should also look at the morality and public order objection.

b. 2.10.1 Base Registry Agreement
Recommendation xx:
ACTION ITEM: Change the text based on text in brackets and strikethrough: “Recommendation xx: There must be a clearer, structured, and efficient method for [applying and negotiating for] obtaining exemptions to certain requirements [provisions] of the [Base] Registry Agreement, [subject to minimum 30-day public comment period] which allows ICANN [Org] to consider unique aspects of registry operators and TLD strings, as well as provides ICANN [Org] the ability to accommodate a rapidly changing marketplace.  [Could encourage applicants to identify requests to amend RA at the time of application submission.]”

Recommendation xx:
ACTION ITEM: Change the text based on strikethrough:  “Recommendation xx:  ICANN must add a contractual provision [in the form of a mandatory Public Interest Commitment] stating that the Registry Operator will not engage in fraudulent or deceptive practices.” Formulate a question for the public comment period about what form this should take (rep, warranty, PIC, etc.).

Notes:

1. Updates to Statements of Interest:

-- Kristine Dorrain is switching to a different role at Amazon and so she will not be representing Amazon on this PDP WG.

2. Discussion of Final Report Topics: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit?usp=sharing

a. 2.8.1 Objections [All Sub-Sections Except GAC Early Warning and GAC Advice - Not Yet Completed], continue discussion on page 73

c. New issues raised in deliberations since publication of the Initial Report, if applicable.
String Confusion Objection: Proposal that there should be grounds for a String Confusion Objection if an applied-for string is an exact translation of an existing string that is in a highly regulated sector, and the applied-for string would not employ the same safeguards as the existing string, subject to the applicant’s governing law.

Discussion:
-- Options discussed on the last call 1) whether to formally adopt some level of PICs that would have requirements built into the contract (GAC Category 1) so there wouldn’t be an objection; 2) not adopt GAC Category 1 and have a dispute process where you allow a dispute to be filed based on the fact that it’s an exact translation and you don’t have the same requirements that others have, or 3) no recommendation either way.
-- In comments received, suggestion that with the potential for confusion from the end user the verified/restricted TLD should build in assurance that a registrant is properly credentialed, such as in medicine.  If you have a word similar in meaning then an end user might assume that the same restriction/credentials would apply.  Makes sense that it could be standing for objection.  Not sure that would take the place of having GAC Category 1 formally adopted.
-- Reluctant to accept the clause, “subject to the applicant’s governing law”.  Added that text because if you can file an objection that an applicant doesn’t implement all of the safeguards the registry currently has because some are contrary to the applicant’s applicable laws.
-- Suggest changing it to “subject to applicable laws”.
-- Yes, to applicable law, not just the applicant's
applicable to where the registrant is based and to where it does business.
-- This has to do with consumer confusion, but not about the string.  It is about the business practice.
-- Not sure the way to do this is through the String Confusion Objection.
-- We are discussing this because it did receive quite a bit of support from commenters, but there was opposition from the Registry SG, Registrar SG, and .brand registries.
-- If we go forward with this then we have to recognize that we are massively changing string confusion, or need to find another way to deal with it.
-- The reason it is “applicants governing law” is because applying all law would eliminate the ability for these strings in different languages to exist.
--  Isn’t the issue not just a countries regulation of pharmacies, but it is a global issue that the string represents a highly regulated industry -- isn’t this something for the GAC to get involved in, or in addition to an objection, such as having standing for the GAC to join in.
-- Think we can agree that this doesn’t fit into the String Confusion Objection and that this may involve other parties.  This also should be connected to the whole notion of Category 1 in general.  We need to reserve time to talk about how we address strings in highly regulated industries. So when we talk about Category 1 in the work plan we also should talk about this issue.
-- Has anyone looked at the morality and public order objection?

ACTION ITEM: Make sure there is time in the Work Plan for the WG to discuss the GAC’s Advice in Category 1 and develop a response to the GAC’s Advice and how to address highly regulated or sensitive strings.  Note that the WG should also look at the morality and public order objection.

b. 2.10.1 Base Registry Agreement, page 74

Recommendation xx: There must be a clearer, structured, and efficient method for [applying and negotiating for] [obtaining] exemptions to certain requirements [provisions] of the [Base] Registry Agreement, [subject to minimum 30-day public comment period] which allows ICANN [Org] to consider unique aspects of registry operators and TLD strings, as well as provides ICANN [Org] the ability to accommodate a rapidly changing marketplace.  [Could encourage applicants to identify requests to amend RA at the time of application submission.]

Discussion:
-- Don’t understand the need for this recommendation -- to allow for exemptions.  This is way to broadly defined.
-- Wondering if "applying for exemptions" or "negotiating for exemptions" rather than "obtaining exemptions" 
would be better.  Also clarify what we mean by “ICANN”.
-- Some TLDs couldn’t launch because they couldn’t get registrars, such as in South America.  There are other things that have come up where applicants have wanted to make changes in the contract, but there was no way to do it.
-- The biggest one was Specification 13 that is an exemption of certain requirements of the Registry Agreement.  That is why this recommendation is so important.
-- Isn’t Specification 13 the exception that proves the rule?  Seems like this undermines everything we’ve done.
-- Without a structured and clear process it can take years to make a commonsense change.
-- Question: How is this different to an Application Change Request?  Answer: This is after the application and isn’t changing part of that application; it is a change request but after the application has been approved.
-- One way to handle this is to put this in the public portion of the application -- that the applicant doesn’t want to adhere to X provision of the RA.  We should recommend that this is in the public portion of the application.
-- One possibility could be a question in the application asking whether the registry plans to ask for any changes to the Registry Agreement and then explain them.
-- The .brand perspective in the last round was that you couldn’t mention your intention without revealing your business plan.  It made sense to have multiple .brands approaching ICANN Org to negotiate and not on an individual basis to get Specification 13.
-- Don’t think we should be requiring applicants to pre-seek exemptions in their applications.
-- If there is a known change that the applicant wants to make to the RA, think we should ask them to make that clear in the application, but only if it is known when the application is submitted.
-- Important to note that ICANN came out with a new base RA after the applications were in and some were approved.  We hope we are guarding against that happening again.

ACTION ITEM: Change the text based on text in brackets and strikethrough: “Recommendation xx: There must be a clearer, structured, and efficient method for [applying and negotiating for] obtaining exemptions to certain requirements [provisions] of the [Base] Registry Agreement, [subject to minimum 30-day public comment period] which allows ICANN [Org] to consider unique aspects of registry operators and TLD strings, as well as provides ICANN [Org] the ability to accommodate a rapidly changing marketplace.  [Could encourage applicants to identify requests to amend RA at the time of application submission.]”

Recommendation xx:  ICANN must add a contractual provision [in the form of a mandatory Public Interest Commitment] stating that the Registry Operator will not engage in fraudulent or deceptive practices.

Discussion:
-- We need to decide if this is a PIC or this is just a stand-alone provision in the Registry Agreement. If a "PIC", then it can be enforced by a third party in addition to ICANN.
-- This is too broad.  No one would sign up to such a contractual requirement.
-- Question: In a situation where there is a PICDRP where the panelists found that there was fraud and ICANN Org said we can’t do anything since fraud isn’t a basis to go after a registry.  How would we address that? Answer: We could state that registries must comply with applicable law and if they were found not to be in compliance then they would be out of compliance.
-- But the RA doesn’t say which law applies.  It’s the law that governs the parties -- ICANN and where the registry is located.
-- You can say what is the applicable law for those parties.
-- Add “under applicable law”?
-- We aren’t recommending changes to the Base RA but we can recommend a PIC.
-- Fraudulent and deceptive practices is specific.
-- So the issue here is that Spec 11 Section 3(a) already requires ROs to require in their RRAs that registrars prohibit fraudulent and deceptive practices (hence the PIC hook) but such provision was found not to apply to the RO itself.  So if "fraudulent and deceptive practices" is specific enough in the existing Spec 11 language it should be specific enough to apply to the RO itself.
-- Suggest we could say, “fraudulent or deceptive practices under applicable law”.
-- We can mirror the language already in Spec 11 3(a) which is already bound by applicable law.  Just make it clear that the prohibited activities apply to the RO itself, not just downstream.
-- Take out “in the form of a mandatory PIC”.  Ask a question to the community as to whether it should be a warranty or a PIC.

ACTION ITEM: Change the text based on strikethrough:  “Recommendation xx:  ICANN must add a contractual provision [in the form of a mandatory Public Interest Commitment] stating that the Registry Operator will not engage in fraudulent or deceptive practices.” Formulate a question for the public comment period about what form this should take (rep, warranty, PIC, etc.).

3. AOB: Letter from GAC.

-- GAC notes that the WG is moving more quickly than the timeline stated in the Project Change Request in moving up the publication of the Draft Final Report.
-- Concern that there won’t be enough time for the GAC to participate and provide input before publication.
-- The Project Change Request noted that this was the worst case scenario and that the WG would try to work more quickly.
-- We did engage the GAC as planned during ICANN67 -- the revised Work Plan didn’t change that.
-- Maybe there’s a way that we can have some issues still be open since there was specific discussion from the GAC that they weren’t commenting at ICANN67 and were waiting for ICANN68.
-- But ICANN68 is not going to be a face-to-face meeting.
-- WG Leadership will discuss the letter and how to respond.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20200409/7829e221/attachment-0001.html>


More information about the Gnso-newgtld-wg mailing list