2020-06-16 New gTLD Subsequent Procedures PDP

Notes/ Action Items

Actions:

Package 3:

2.3.3 Applicant Freedom of Expression

1. Recommendations and/or implementation guidelines

Implementation Guidance xx:

As the ICANN organization and community incorporate human rights into ICANN’s processes in line with the recommendations of CCWG-Accountability Work Stream 2, they may want to [should] consider the application of this work to elements of the New gTLD Program.

ACTION ITEM: The WG agrees to change “they may want to” to “they should”, per the standard language for implementation guidance.

Package 4:

2.7.5 Internationalized Domain Names

1. Recommendations and/or implementation guidelines

Recommendation xx (Rationale 4):

ACTION ITEM: Accept the suggested edits in Recommendation xx (Rationale 4).

ACTION ITEM: Investigate definition of variant and add as footnote.  Added citation directing to IDN Variant TLD Implementation: Motivation, Premises and Framework, which discusses the definition and provides examples.

Rationale for Recommendation xx (rationale 4):

ACTION ITEM: Delete “owned and” before “operated” and add “if delegated” after “service provider”.

2.7.7 Applicant Reviews: Technical/Operational, Financial and Registry Services

Registry Services

Recommendation xx (rationale 11):

ACTION ITEM: The WG agrees to add “base” before “Registry Agreement”.

2.7.8 Name Collisions

1. Recommendations and/or implementation guidelines

Implementation Guidance xx (Rationale 4):

ACTION ITEM: Move the additional language to the rationale section.

ACTION ITEM: Replace the previous text with the next text suggested:  Implementation Guidance xx (Rationale 4): The ICANN community should develop name collision risk criteria and a test to provide information to an applicant for any given string after the application window closes so that the applicant can determine if they should move forward with evaluation.

Implementation Guidance (Rationale 5)

ACTION ITEM: Add text in brackets and delete text in strike out: ICANN should also seek to identify aggravated risk strings [in advance of the next application window opening and whether it would], which would be expected to require a specific name collision mitigation framework. However, all applied-for strings should be subject to a DNS Stability evaluation to determine whether they represent a high, aggravated, or low risk of name collision.

ACTION ITEM: Move the text on the DNS Stability Evaluation into a separate Implementation Guidance.

Rationale for Affirmation xx (Rationale 3):

ACTION ITEM: The WG agreed to include the additional text, but not the text that begins “the working group has been advised Co-Chairs of the NCAP...”  Also, the WG agreed to delete the associated footnote.

Notes:

1. Updates to Statements of Interest: No updates provided.

1. Review “Can’t Live With” comments on package 3 – additional comment from Anne Aikman-Scalese on page 38. See the Production document at: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQLuQuo/edit?usp=sharing.

2.3.3 Applicant Freedom of Expression

1. Recommendations and/or implementation guidelines

Implementation Guidance xx:

As the ICANN organization and community incorporate human rights into ICANN’s processes in line with the recommendations of CCWG-Accountability Work Stream 2, they may want to [should] consider the application of this work to elements of the New gTLD Program.

ACTION ITEM: The WG agrees to change “they may want to” to “they should”, per the standard language for implementation guidance.

1. Review “Can’t Live With” comments on package 4, start on page 57: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQLuQuo/edit?usp=sharing

2.7.5 Internationalized Domain Names

1. Recommendations and/or implementation guidelines

Recommendation xx (Rationale 4):

Discussion:

-- Decided on the last call not to accept the alternate language.

-- There is work that will be initiated by the GNSO Council on this, as we point out in the rationale.

-- Need to be identified as “IDN” variants specifically, and “IDN gTLDs”; replace “allowed provided they” with “only if they”.

-- With respect to translations – it’s possible for a variant to be a translation, but not all translations are variants.

-- We are specifically calling out the variant, as opposed to the translation.  Can we give the IRT more information?   Look at Recommendation xx (Rationale 2): “Recommendation xx (rationale 2): Compliance with Root Zone Label Generation Rules (RZ-LGR) must be required for the generation of IDN TLDs and variants labels, including the determination of whether the label is blocked or allocatable.”

-- People are confused by what is a variant and what is a translation.  Can we put in examples?

-- Need to keep it as simple and as accurate as possible.

ACTION ITEM: Accept the suggested edits in Recommendation xx (Rationale 4).

ACTION ITEM: Investigate definition of variant and add as footnote.  Added citation directing to IDN Variant TLD Implementation: Motivation, Premises and Framework, which discusses the definition and provides examples.

Rationale for Recommendation xx (rationale 4):

ACTION ITEM: Delete “owned and” before “operated” and add “if delegated” after “service provider”.

2.7.7 Applicant Reviews: Technical/Operational, Financial and Registry Services

Registry Services

Recommendation xx (rationale 11):

-- Suggestion from Rubens to add “base” before “Registry Agreement”.

ACTION ITEM: The WG agrees to add “base” before “Registry Agreement”.

2.7.8 Name Collisions

1. Recommendations and/or implementation guidelines

Implementation Guidance xx (Rationale 4):

Discussion:

-- Additional suggested language seems more appropriate for the rationale section.

-- No need to mention Jeff Neuman, we can say that there are some participants that are some working group members that are participants in the NCAP. We don't even need to say that weekly conference calls or anything but just to say that there's an NCAP group, which I think we mentioned in the rationale.

-- There also is suggested alternative text for the Implementation Guidance (Rationale 4).  This was suggested by Jim Prendergast to align with what Jim Galvin told us on the 30 April call.

ACTION ITEM: Move the additional language to the rationale section.

ACTION ITEM: Replace the previous text with the next text suggested:  Implementation Guidance xx (Rationale 4): The ICANN community should develop name collision risk criteria and a test to provide information to an applicant for any given string after the application window closes so that the applicant can determine if they should move forward with evaluation.

Implementation Guidance (Rationale 5)

Discussion:

-- The additional language with the reference to dependencies is more appropriate to be included in the rationale section.

-- Include text that the identification of risk strings should happen in advance of the next application window opening, but don’t include that it should be published in the Applicant Guidebook.

-- Limiting to say that it must be published in the AGB.

-- But we want to give as much information in advance.

-- This is going out for public comment.  We don’t want to be too prescriptive at this point.

-- Put the text on the DNS Stability Evaluation as a separate Implementation Guidance.

ACTION ITEM: Add text in brackets and delete text in strike out: ICANN should also seek to identify aggravated risk strings [in advance of the next application window opening and whether it would], which would be expected to require a specific name collision mitigation framework. However, all applied-for strings should be subject to a DNS Stability evaluation to determine whether they represent a high, aggravated, or low risk of name collision.

ACTION ITEM: Move the text on the DNS Stability Evaluation into a separate Implementation Guidance.

Rationale for Affirmation xx (Rationale 3):

ACTION ITEM: The WG agreed to include the additional text, but not the text that begins “the working group has been advised Co-Chairs of the NCAP...”  Also, the WG agreed to delete the associated footnote.