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

[Julie Hedlund]

Dear Working Group members,

Please see below the notes from the meeting on 18 June 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-06-18+New+gTLD+Subsequent+Procedures+PDP.

Kind regards,
Julie

Notes and Action Items:

Actions:

Review Category 1/Verified TLDs Draft Framework:

ACTION ITEM: Use “program” to refer to the NGPC document, and use “framework” to refer to this document/proposal.
ACTION ITEM: On Question #5: Agree that it’s a panel, waits on the determination until after public comment closes, can include experts, not sure if it has to wait until the GAC Early Warning is concluded.  Discuss the last item on the list.

Review "Can't Live With" comments on package 5, start on page 79:
Affirmation xx (rationale 1):
ACTION ITEM: Incorporate the concept/language from Ruben Kuhl, but don’t leave it open ended -- include that in only changes based on the processes.

Notes:

1. Updates to Statements of Interest

2. Review Category 1/Verified TLDs Draft Framework:
See https://docs.google.com/document/d/1DlFCp9cCks7WySF1bqMbFJEg-IpCOoMNQsfIQs4QYcU/edit?usp=sharing
Also, see the Category 1 Safeguards at: https://www.icann.org/en/system/files/files/resolutions-new-gtld-annex-2-05feb14-en.pdf

ACTION ITEM: Use “program” to refer to the NGPC document, and use “framework” to refer to this document/proposal.

Discussion:
-- The framework doesn’t try to bless GAC advice, but provides information for the applicant.
-- Soften the language -- such as under the proposal #3 could be “may warrant”.
-- Can’t mandate where applicants can or cannot come from or where they should incorporate.

QUESTION:  Who makes the ultimate determination of whether it is one of the 4 categories?  The GAC?  A Panel?  ICANN BOARD?
-- Seems like a Panel is the only reasonable option, but then we have to build a process for the Panel.
-- I think with the Board because they are the ones that have to deal with GAC Advice.  GAC may give advice this time that is specific to the four categories and you don't want conflict between a panel decision and GAC Advice - that is untenable for the Board.

-- Where do we get input from? GAC, public comment?  Make sure public comment is there.
-- Whatever we set up would rely on GAC advice as well as public comment.
-- If an applicant is going to roll out a TLD that sounds regulated but will be using it for a non-regulated purpose, the application needs to say that.
-- How will the Board resolve any difference between the Panel and the GAC.
-- The Board could reverse the panel.
-- Isn’t the Board a kind of a panel representing the multistakeholder society?
-- Panel would not prevent the Board or GAC from weighing in.
-- Can the Board override a panel in following the GAC Advice?
-- We are talking about an evaluation process.  Maybe “panel” is confusing.  We aren’t talking about something that isn’t already there.
-- Keep it simple and make it like the other panels, taking into account GAC Advice and public comment, but keep the panel processes very similar.
-- The NGPC was effectively the panel last time.
-- Should be a panel with clear ideas of what to check.
-- What order do you do things?  Does the GAC provide input to the panel?  You can make sure that the evaluation panel doesn’t start until the public comment period ends.  GAC members could file comments.  Then the panel makes it decision and then the GAC can provide Advice on the panel’s determination, which will be helpful to the Board.
-- Good to place evaluation post public comment. Public comment may help pick up applications which did not self-identify but should have
-- Panel should have the power to appoint specialists or experts.  Could say a panel of experts in global regulated industries.
-- 1. Self-categorization, 2. Panel should have power to add specialists and experts, 3) Timing - to follow Early Warnings and Public comment
-- Don’t know if we need to have it follow Early Warnings.
-- Bullet no. 2: “This framework does NOT seek to create definitive criteria to identify which strings belong to which group (i.e., this is not an evaluation element of the program)” needs to be deleted or amended.  Delete the parenthetical.

ACTION ITEM: On Question #5: Agree that it’s a panel, waits on the determination until after public comment closes, can include experts, not sure if it has to wait until the GAC Early Warning is concluded.  Discuss the last item on the list.

3. Review "Can't Live With" comments on package 5, start on page 79: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQLuQuo/edit?usp=sharing and also see the attached Word document of comments on the Work Track 5 Final Report

2.7.1 Reserved Names

Recommendation xx (rationale 3): The Working Group recommends reserving as unavailable for delegation at the top level the acronym associated with Public Technical Identifiers,  “PTI”.

[Proposed alternate text for Recommendation xx (rationale 3): The Working Group recommends reserving as unavailable for delegation at the top level the strings
“PUBLICTECHNICALIDENTIFIER”, “PUBLICTECHNICALIDENTIFIERS” and “PTI”, all of which are associated with Public Technical Identifiers.]

JC5.1 - Justine Chew proposed alternate text for Recommendation xx (rationale 3). Rationale: "It is noted that discussion in the WG led to a recommendation for just the acronym “PTI” be reserved as unavailable for delegation at the top level. However, given that the PTI is a core service that the Internet relies on, the At-Large thinks that “PUBLICTECHNIDENTIFIER” and “PUBLICTECHNICALIDENTIFIERS” should also be recommended to be reserved and unavailable for delegation at the top level, which is consistent with preliminary recommendation 2.7.1.c.1 of the SubPro Initial Report. Recommending that they be reserved would disallow them from being applied which is more optimal than subjecting the ICANN community to a need to file objections against any applications for PUBLICTECHNCALIDENTIFIER” and/or “PUBLICTECHNICALIDENTIFIERS”, and to altogether avoid any risk of misuse of these strings."

Discussion:
-- We are reverting to the same standard that has been used for reserved names -- that is, just reserving the acronym rather than the full name.
-- Are we creating an issue where an issue doesn’t exist?  The entities that all have only their acronyms protected have never raised an issue (SSAC, GNSO, ccNSO, IANA…).
-- We didn’t get any comments that said that the full names of these organizations need to be protected.
-- Should we treat this as a new idea and get public comment on it?  We are putting it in because there was a comment that PTI needed to be reserved.
-- The WG did not agree to include the revised language.

Affirmation xx (rationale 1): The Working Group supports continuing to reserve as unavailable for registration those strings that are currently considered Reserved Names at the second level as of the publication date of this report and as required by future Consensus Policy.

[Proposed alternate text for Affirmation xx (rationale 1): “The Working Group supports subsequent procedures gTLDs continuing to follow the same schedule of reserved names at registration level(s) that 2012 gTLDs have to follow, which might change from time to time.”]

RK5.1 - Rubens Kuhl proposes alternate text for Affirmation xx (rationale 1) above. Rationale: "Text would freeze 2nd level reserved names as they are today, not accounting for possible changes, as described in one rationale for this section that correctly foresees the list to be updated."

ACTION ITEM: Incorporate the concept/language from Ruben Kuhl, but don’t leave it open ended -- include that in only changes based on the processes.

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