2020-12-03 New gTLD Subsequent Procedures PDP

Notes/ Action Items

Action Items:

Topic 26: Security and Stability

Rationale 26.4: It means that ICANN should strive for 5% and if for whatever reason it believes a different percentage should apply, it must either run that by the IRT (if before the AG) or through the Predictability Framework if after.

ACTION ITEM: Add language to clarify re: Predictability Framework and IRT.

ACTION ITEM: Re 26.7 -- Rephrase this Implementation Guidance as a general suggestion to ICANN org rather than a specific department.  Also, need to clarify if we should change Root Zone Manager to Root Zone maintainer.

ACTION ITEM: Need to update IG 26.8 based on new OCTO document on Root Zone early warning system. “ICANN should continue the work on the early warning monitoring system.”  Also point to the OCTO paper and comment period in the rationale.  Review the OCTO paper in case we need to further adjust the language.  Circulate the revised language to the WG to review.

ACTION ITEM: 26.9: Recommend keeping language the same and including ICANN's comment in the Rationale section. Since this WG did not do the work cited by ICANN org, it does not seem appropriate to change the wording in the Recommendation itself.

Topic 29: Name Collisions

ACTION ITEM: Update the rationale of this section as to the current status of Study 2.  Reflect the fact that the Board will not be acting on Study 2 until after the issuance of the Final Report and we should say our recommendations could be affected by further Board actions.

ACTION ITEM: Discuss with leadership team and staff as to whether new Implementation Guidance should be developed for how the IRT should proceed with respect to the recommendation for a test to determine if there are any high-risk labels.

Topic 11: Universal Acceptance

ACTION ITEM: Implementation Guidance that it would be useful for data to be collected by the UASG prior to the next round for the IRT.

Notes:

1. Updates to Statements of Interest:

-- Maxim Alzoba will be temporarily representing the RySG on the SSC through December.

2. Review draft Final Report Public Comments – to prepare see the links to the Public Comment Review Tool on the wiki at: https://community.icann.org/display/NGSPP/h.+Published+Draft+reportsand review the following topics and comments:

Topic 26: Security and Stability

Row 14 – ICANN Org

Leadership Comments:

26.2: No, conservatism does not mean the rates that were in 2012. It means that when presented with a number of options, ICANN errs on the side of caution in general. Given the comments we have received and the reports we have reviewed, we believe the recommendations in this section about looking at the rate of change is "conservative."

IG 26.4: No, this has nothing to do with the SLAs, but rather governs when a registry operator may submit a valid request for delegation.

Re: “Rationale for Implementation Guidance 26.4: The PDP WG notes "further work should be done on establishment of an appropriate rate for delegation," but this guidance says not more than five percent per month. Should it be interpreted that five percent per month is the upper-bound but ICANN could implement a lower bound if it is deemed appropriate? Implementation Guidance 26.6”

Rationale 26.4: It means that ICANN should strive for 5% and if for whatever reason it believes a different percentage should apply, it must either run that by the IRT (if before the AG) or through the Predictability Framework if after. ACTION ITEM: Add language to clarify re: Predictability Framework and IRT.

1. IG 26.6: This is directly excepted out of SAC 100. Perhaps the question is better addressed to them as opposed to us.

1. 26.7: Agree with ICANN Recommendation as to the change in wording, but not on the last sentence which implies that the RZERC redo everything that we (the WG) and the SSAC have done on this subject.

ACTION ITEM: Re 26.7 -- Rephrase this Implementation Guidance as a general suggestion to ICANN org rather than a specific department.  Also, need to clarify if we should change Root Zone Manager to Root Zone maintainer.

ACTION ITEM: Need to update IG 26.8 based on new OCTO document on Root Zone early warning system. “ICANN should continue working on the feasibility of the early warning monitoring system.”

ACTION ITEM: 26.9: Recommend keeping language the same and including ICANN's comment in the Rationale section. Since this WG did not do the work cited by ICANN org, it does not seem appropriate to change the wording in the Recommendation itself.

Row 15 – SSAC comments in meeting on 19 October 2020 – see: https://gnso.icann.org/sites/default/files/policy/2020/transcript/transcript-gnso-subpro-19oct20-en.pdf

Topic 29: Name Collisions

Row 11 – ALAC re: Subject to recommendations of SSAC/NCAP; Row 14 – IPC re: Some support for 90-day controlled interruption; some support for NCAP to develop tests for risk and mitigation measures.

Leadership Comments:

Noted. This has been exhaustively discussed. Studies 2 and 3 are not yet fully scoped (nor will be by the time we finish our report). In addition, they still MUST be approved by the Board. Finally, the delegation of nearly every string will pose a "risk" of name collision. It’s the quantification of that risk along with the mitigation of that risk that is the real question. Finally, we note your request that the SSAC study the risks (if any) of Man in the Middle attacks. But this request should go to them and not to us.

ACTION ITEM: Update the rationale of this section as to the current status of Study 2.  Reflect the fact that the Board will not be acting on Study 2 until after the issuance of the Final Report and we should say our recommendations could be affected by further Board actions.

Row 15 – ICANN Board re: Provide details on how future NCAP study result should be dealt with in future rounds.

Leadership Comments: To the extent that there are any new recommendations as a result of the work of the NCAP, and those recommendations have an impact on the new gTLD program (either as a whole or with respect to future individual applications), then those should be introduced like all other changes, through the Predictability Framework. If the recommendations involve changing the policies (or adding new policies), then the Predictability Framework will involve the GNSO through its processes. See Topic 2.

Discussion:

-- Assume that the name collision policy would apply to all rounds in future.

-- Question: How will the WG respond to the Board concerning its questions? Answer: The plan is to focus on getting the Final Report out with some possible changes to rationale where appropriate.  After the report is out craft a response to the Board on why we did what we did.

-- Concerned about potential delays where policy issues may be involved.

-- SSAC said on 19 October that they are not creating dependencies on the outcome of the NCAP.  So it doesn’t make sense for the WG to create dependencies.  See also: https://www.icann.org/en/system/files/correspondence/chalaby-to-drazek-et-al-01nov19-en.pdf.  Board doesn’t say that it should be a dependency and doesn’t seem to be agreement in this WG that it should be a dependency.

-- The relevant issue for us is how do we address community efforts and recommendations that may come after we have concluded our work? Notwithstanding NCAP is the issue we are discussing now, there is potential for other subjects to collide in some way with our recommendations. So wouldn't it be prudent for us to have a high level discussion about how to account for those situations? The recommendation from leadership on this topic may be appropriate more broadly.

-- We’ve built in processes to handle changes that occur before or after the AGB and round.

Row 16 – ICANN Org re: Concern about technical challenges as a result of Implementation Guidance.

Leadership Comments: Question back to ICANN: When a TLD is delegated, nic.TLD is put into the zone and is sent to the registry NIC page (and also to whois.nic.tld). How would exempting a name out of the Wildcarding process be any different. In other words, the impacts second level name could return an NXDOMAIN response, the NIC.TLD would return the usual response to the registry page, and every other name would return the specified controlled interruption page. Why would you need to suspend controlled interruption for every name if there is an issue with one label?

Additional Questions for ICANN Org:

-- First question is on the second example -- there was no generally available DNS implementation of Controlled Interruption prior to its artificial creation during the 2012 new gTLD round, so how difficult would this (or something like this) be to implement (recognizing that we have at least 2-3 years prior to a new TLD even being near delegation into the root).

 -- Second question is whether there are any other alternatives other than the extreme alternatives presented by the ICANN comment of either stopping controlled interruption for everything for 1 name?

 -- Third question is whether there were any examples in the 2012 round that they were aware of where this situation would have come into play.  [Namely, what is the real risk of this edge case]

 -- Fourth question is If this is not possible, then why does ICANN state this in their proposed Name Collision plan for ccTLDs: “Managers of new ccTLDs are recommended to have a name collision reporting mechanism to act upon cases of severe harm (e.g., clear and present danger to human life) caused by name collision for, at least, the early days of the life of the new ccTLD's operation (please see for example <https://forms.icann.org/en/help/name-collision/report-problems>). Examples of measures that may be taken would include: removal of wildcard records from DNS during the controlled interruption period; removal of a second-level domain name from the DNS; and in extreme cases, removal of the TLD itself from the root zone (e.g., in case of harm caused by the TLD itself – dotless name – during the controlled interruption period). Note that these measures are only intended to be temporary while the affected party effects changes in their network configuration to avoid future harm (https://www.icann.org/resources/pages/cctld-mitigation-2014-10-02-en [icann.org]).”

Discussion:

-- If the recommendation is for there to be a test to determine if there are any high-risk labels, and the IRT comes back and says based on the NCAP that a test isn’t feasible, it could be a policy issue.

-- The IRT needs to converse with the NCAP, Board, etc. and decide what can be done and come back to the GNSO Council if it isn’t feasible.  We haven’t provided any guidance on how the IRT should work.

ACTION ITEM: Discuss with leadership team and staff as to whether new Implementation Guidance should be developed for how the IRT should proceed with respect to the recommendation for a test to determine if there are any high-risk labels.

Topic 11: Universal Acceptance

Row 8 – ARTICLE 19 re: More should be done on UA - metrics on adoption.

Leadership Comments: Noted. But what data will registries and registrars have on UA of issues that occur at other layers of the Infrastructure (namely applications).

Row 11 -- Swiss Government OFCOM; dotBERLIN GmbH & Co. KG; Hamburg Top-Level-Domain GmbH and Row 12 -- InfoNetworks LLC re: More should be done on UA and Row 17 – ALAC re: suggested metrics

Leadership Comments: Noted. And this can be directed to the UASG

Row 13 – ALAC re: More should be done on UA - metrics on adoption, promotion of UA-readiness.

Leadership Comments:

Noted. The WG could discuss the following points

1. UA generally deals with the ability of third parties to accommodate new gTLDs (labels). Judging success of a program based on what third parties not under the auspices of ICANN and not within the control of the registries and registrars would not be appropriate. A program's success or lack thereof should only be measured by factors that can be controlled by the program being measured.
2. The ability to accept IDN second level registrations has not been a UA problem in years. Every registry and registrar that offers domain names for sale in a particular language/script by definition can accept, transmit and register IDN second levels. The problem is at the application layer, not the infrastructure layer.
3. Noting the above points, then what metrics (beyond perhaps a before and after next round comparison of data collected by the UASG) could be proposed, within the context of our SubPro remit

Discussion:

Re: “…and the public disclosure of policies available to ensure the successful adoption of Universal Acceptance across all registries and registrars.”

-- How can you judge the success or failure of a program as a whole on the basis of actions outside of the control of the program, i.e., third parties?

-- Also the issue of whether registries or registrars have applications that are accessible in all languages and scripts.  You could do something on that from a compliance level, but not with third parties outside of ICANN control.   Registries and registrars rely on third-party platforms.

-- This isn’t only applicable to IDNs.  Ensure that there is an adequate communication program next time.

-- Our recommendations refer to the work of the UASG and that it should continue.  One of our recommendations is to the IRT to collect data.

-- If the metrics is already being collected can those be referred to? And I also don't think that promotion of UA readiness is a bad idea, notwithstanding Jeff's point that much of the problem is outside registries and registrars.

-- And note too that the current focus on UASG work also includes provision of a lot of education material for implementation that should be activity around the timing of the next round as well. Data captured therefore will be useful (and interesting to some of us).

ACTION ITEM: New Implementation Guidance that it would be useful for data to be collected by the UASG prior to the next round for the IRT.

Topic 40: TLD Rollout

Row 8 -- GoDaddy Registry re: Require Registry Operators to show "use" of the TLD within 1 year of delegation.

Leadership Comments: New Proposal; Discuss with WG. But this would be incredibly subjective

Discussion:

-- Be clearer about what we mean by “use”.

-- We spent quite a bit of time discussion “use”.

-- We know in the case of some applicants they may have intent to launch, but having a 12-month launch could be unreasonable.  Some may want to wait to launch during a quiet period.

-- Also agree that until there are real protections for .brands (i.e. ICANN has to do a trademark search before it sells a TLD to someone that contains someone else's brand) in this program, we don't want to be dictating how much "use" a .brand needs to undertake.  Keeping your brand from being squatted to death is a very important use.

-- Lots of reasons why a registry may want to delay, some by choice and some by necessity.