[Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 14 April at 3:00 UTC

[Emily Barabas]

Dear Working Group members,

Please see below the notes from the meeting on 14 April at 3:00 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/x/nC2JBw

Kind regards,
Emily


ACTION ITEMS:

ACTION ITEM (Base Registry Agreement): Include question for public comment about Code of Conduct exemption.

ACTION ITEM (Base Registry Agreement): Include question for public comment about whether contractual provision stating that the RO will not engage in fraudulent and deceptive practices should be in the form of a PIC.

ACTION ITEM: Under “Recommendation xx (rationale 2): The addition of Registry Voluntary Commitments must require public comment.” Ensure that this recommendation includes all items discussed that must require public comment.

ACTION ITEM (Application Change Requests): Include recommendation for .brands to be able to change the applied-for string under narrow circumstances. Include question for public comment on whether there should be other circumstances where the applicant can change the applied-for string and also request input on whether any additional guardrails are needed.

NOTES:

1. Review Agenda/Updates to Statements of Interest
- Request from WG member to ensure that there is sufficient time to discuss the letter from the GAC under AOB.
- Request noted by leadership. Ten minutes will be left at the end of the call.
- First batch of draft final sections will go out today. These will be sent with a form for members to fill out and send by email if there are items that they “can’t live with.” Comments should include proposed edits to resolve the identified issue. These proposed edits should be in line with previous discussions.
- The sections that will be released are: Systems, Communications, Fees, Applicant Guidebook, Application Submission Period
- WG members will have 7 days to review the sections and provide feedback.
- Confirmation that this is an additional refinement step. This is not a consensus call. There will be an opportunity to make any final adjustments in the weeks before the report is published for public comment.
- Consensus call will take place after final revisions are made following public comment.

2. Discussion of Final Report Topics: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit?usp=sharing [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU_edit-3Fusp-3Dsharing&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=6_6uJcJ_8Di93BJYPNxu7gHa5bsOKi5X5fL6J-o8cBw&s=_76BWCkrGEIpA6zwus_WOFyzVChcDeGC5eY8Jq63HPA&e=>

a. 2.10.1 Base Registry Agreement, Section C New Issues, start on page 77
- Topic under part C – Code of Conduct exemption for registries that have made a good faith effort to get registrars to carry the TLD, but were unable to do so. Should this be a recommendation or IG?
- Question – do we know how many registries are in this position?
- Answer – there is only anecdotal evidence of this issue. Data is not available.
- Question – what are the current grounds for exemption?
- Answer – the only way to gain an exemption currently is included at the end of Spec 9. They have to meet all criteria. They have to be a single registrant TLD. They may not qualify for Spec 13. They have to provide a justification that there is no harm to the public interest by having the exemption. See https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit?usp=sharing
- Some support expressed for including this item as a recommendation to support innovation.
- Counter-argument – this only impacted a few registries is the 2012 round, registries should do due diligence before they apply to make sure there is a distribution channel.
- Question – what is the standard for evaluating candidates for this exemption?
- Answer – there are no purely objective standards to determine what constitutes a good faith effort. Registries should be able to show the reached out to registrars. The WG would need to leave some discretion to ICANN org.
- Suggestion – include proposed standards in the question that goes out for public comment. Question could include request for input on how to evaluate those seeking the exemption.
- Some support for including as a question for public comment.

ACTION ITEM (Base Registry Agreement): Include question for public comment about Code of Conduct exemption.

- Discussion topic - contractual provision stating that the RO will not engage in fraudulent and deceptive practices.
- Agreement that there should be a question for public comment about whether this should be a PIC.

ACTION ITEM (Base Registry Agreement): Include question for public comment about whether contractual provision stating that the RO will not engage in fraudulent and deceptive practices should be in the form of a PIC.

b. 2.4 Application Change Requests, page 79
- Comment – need to make sure that the previous discussions under other topics are reflected in this section regarding which types changes require public comment.

ACTION ITEM: Under “Recommendation xx (rationale 2): The addition of Registry Voluntary Commitments must require public comment.” Ensure that this recommendation includes all items discussed that must require public comment.

- From the 2012 round, there was a list of items that do not require public comment. The challenge of listing all items that do require a public comment is that you might miss something. The Working Group might want to include an exemplary list of items that require public comment and may also include items that will not require public comment, drawing on the list from 2012.
- WG members are encouraged to provide feedback on this item on the mailing list.
- Note that ICANN Org requested that the WG provide additional guidance with respect to Recommendation xx (rationale 3) – details of this request are included as a comment in the document.
- This recommendation touches on a few different issues and may need to be reworked.
- It may make sense to revisit these recommendations after the section has been revised and see if the ICANN org concerns are addressed.
-Review of proposal to allow applicants to change the applied-for string in part c of the section. There are currently no recommendations on this topic.
- We have ruled out the ability of applicants to change the string under all circumstances. We are focused on some possible, narrow exceptions, specifically:
- in response to an objection, for example GAC Advice – example: The GAC issues advice against a brand name, but is comfortable with the a TLD that includes the name plus “company.”
- Two or more .brand applicants apply for the same string. The parties agree that one or both applicants change the applied for string. Example – two brands apply for .sas, one of the applicants could change the applied-for string to .sassoftware or similar.
- In both cases, changes would be subject to public comment and would trigger an opportunity for objections. The new string must not create a new contention set or expand an existing contention set.
- Concern expressed about potential gaming. WG would need to narrowly define circumstances where this is allowed to prevent gaming.
- Some support expressed for this narrow solution as a common-sense approach, noting that there needs to be a process and criteria for implementation.
- Feedback that if this proposal becomes a recommendation, their needs to be appropriate guardrails in place.
- If this is included as a recommendation, it should be accompanied by a question for public comment.
- Is this proposal too limited? Should there be other circumstances where a change should be permitted?
- From one perspective, if guardrails are in place (public comment, ability to object, no new contention set), the proposal could be broader, might not even need to limited to brands.
- Suggestion that the discussion of guardrails should be more specific – must need to comply with all other rules of the program related to applied-for strings (name collisions, IDN variants, etc).
- Some support had been expressed on previous calls for the proposal only if it is narrowly tailored.

ACTION ITEM (Application Change Requests): Include recommendation for .brands to be able to change the applied-for string under narrow circumstances. Include question for public comment on whether there should be other circumstances where the applicant can change the applied-for string and also request input on whether any additional guardrails are needed.

- What about allowing a change, using the same guardrails, in response to other types of objections, not only GAC Advice?
- Feedback from ICANN org – the proposal regarding .brands changing the applied-for string  could potentially change the criteria used for Spec 13. Under the current criteria, one of the things that is looked at is whether the string is an exact match of a trademark.
- Response – they would first have to qualify to be a .brand, only in that circumstance would they qualify to change the applied-for string. The new string would also need to be considered at brand TLD, which would be a narrow exception to the exact match.
- Comment: From a common sense perspective, it makes sense to have an exception, but is it unfair to companies who would like to apply for the exact match of their brand name and it is not available for some reason, but they can’t apply for an alternate string as a .brand.
- Example: GE could not apply for .ge, but they were told that something like .gecompany could not be a .brand and they would have to apply for an exemption to create a quasi-.brand.
- Possible alternative if the WG does not believe the new string should be eligible as a .brand - the new string could be eligible for a Code of Conduct exemption instead.

3. AOB - Letter from the GAC
- GAC raised concerns about the current timeline that the PDP is following in light of COVID-19 and would like to see the PDP follow the worst-case scenario timeline included in the GNSO Project Change Request.
- Suggestion from WG member – Submit a Final Report on the current schedule covering all topics except the 5 that most interest the GAC and then submit a supplemental Final Report after ICANN68 that focuses on the five issues that most interest the GAC.
- Jeff’s response – The GAC has already given really good feedback on those five issues that the WG can take back and discuss. It is too early at this stage to know if we need to proceed with a new plan.
- The PCR presents a worst case scenario, so it is unclear why the GAC is relying on that document. This is something that the WG should continue to discuss.
- Cheryl’s response – there could be an opportunity to collect additional input from the GAC on the five topics as long as it doesn’t impact the overall timeline of the report.
- Jeff’s response – we will welcome the GAC’s response during the public comment period.
- Question - the Work Plan still reflects a start date of the public comment period of July 20, is this current?
- Response - the current goal is to get the report out before ICANN68. The Work Plan needs to be updated to reflect this.
- Comment – is there a way to enable additional GAC input on the topic that interest them during ICANN68?
- Note that SubPro co-chairs spent a significant amount of time with the GAC during ICANN67 ensuring that GAC members were up to speed and had an opportunity to provide input.
- Suggestion to reduce frequency of calls.
- Leadership would like to keep the current frequency to continue the current momentum.
- In slides for ICANN67, we said the timeline depicted was a worst case scenario, but there is still likely an opportunity for outreach to the GAC, in particular from the Council. The Council may want to connect with the GAC about its renewed emphasis on building more conservative timelines for projects, which may result in projects moving ahead of those timelines.


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