Note
Notes/ Action Items Actions: 2.8.2 Post-Delegation Dispute Resolution Procedures ACTION ITEM: Add a footnote that there is another rights protection mechanism -- the TM-PDDRP -- that is being reviewed by the RPMs PDP WG. ACTION ITEM: Change the name “Post-Delegation Dispute Resolution Procedures” to “Registry Commitments Dispute Resolution Process”. ACTION ITEM: Clarify that the PICDRP applies to both mandatory PICs and RVCs. 2.7.1 Reserved Names: Affirmation xx (rationale 1): ACTION ITEM: Insert a link in a footnote to the AGB where the reserved names are listed. ACTION ITEM: Double check to see whether it is necessary to add text noting that the reserved names list has been modified. Recommendation xx (rationale 3): ACTION ITEM: Change to “The Working Group acknowledges…” and add reference to the MOU in the rationale. Recommendation xx (rationale 4): ACTION ITEM: Change to “second-level Letter/Letter Two-Character ASCII Labels”. Rationale for Recommendation xx (rationale 2): ACTION ITEM: Only note reservation of acronym “PTI”. 2.2.4 Different TLD Types: Recommendation xx: ACTION ITEM: Change in the first sentence from “type of applicant” to “type of application” and “or the registry focus” to “or the applicant type”. Notes: Updates to Statements of Interest: No updates provided. 2. Discussion of Final Report Topics: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit?usp=sharing WG Review of Final Report Draft Recommendations: See: https://community.icann.org/x/JDKJBw -- Includes comments on the first Package of Report topics. -- Second package will be released on 23 April: 2.10.2 Registrar Non-Discrimination / Registry/Registrar Standardization  2.5 Registrar Support for New gTLDs  2.11.1 Registry System Testing  2.12.1 TLD Rollout  2.12.3 Contractual Compliance  -- Note that some recommendations on metrics have been removed. These will be put in a separate section on key metrics and service levels. -- Question: How will comments be addressed? Answer: We will incorporate the proposed new language and dedicate time at meetings to discuss them. If there is agreement then they will be incorporated, if not then they won’t. -- There weren’t many comments received on the first package. -- 04 May will be the next 120-minute meeting. -- 30 April we will talk about Name Collisions and we’ve invited the Chairs of the NCAP; Jim Galvin, Matt Thomas, and Matt Larson from OCTO. a. 2.8.2 Post-Delegation Dispute Resolution Procedures ACTION ITEM: Add a footnote that there is another rights protection mechanism -- the TM-PDDRP -- that is being reviewed by the RPMs PDP WG. -- Dispute Policies is a good substitution for Dispute Resolution Procedures. But I do not see the difference between Post-Delegation and After Delegation. It means the same, and at least legally, it is usual to use the words “post” and “ante” for after and before. -- Need to reference the Registries voluntary commitments -- and maybe call it the Registry Commitments Dispute Resolution Process. -- We definitely need to distinguish between mandatory PICs and Registry Voluntary Commitments. -- Note that in the Registry Commitments section there is this Implementation Guidance xx (rationale 5): The Public Interest Commitment Dispute Resolution Process (PICDRP) and associated processes should be updated to equally apply to RVCs. -- Helpful to differentiate between the two types of PICs -- voluntary versus mandatory -- especially for the public. -- We could still call it the PICDRP would apply to RVCs. We could leave it as PICDRP. -- Important to specify that PICDRP covers all registry commitments - both mandatory PICS and RVCs. ACTION ITEM: Change the name “Post-Delegation Dispute Resolution Procedures” to “Registry Commitments Dispute Resolution Process”. ACTION ITEM: Clarify that the PICDRP applies to both mandatory PICs and RVCs. b. 2.7.1 Reserved Names (p 40) Affirmation xx (rationale 1): The Working Group supports continuing to reserve as unavailable for delegation those strings at the top level that were considered Reserved Names and were unavailable for delegation in the 2012 round. ACTION ITEM: Insert a link in a footnote to the AGB where the reserved names are listed. ACTION ITEM: Double check to see whether it is necessary to add text noting that the reserved names list has been modified. Recommendation xx (rationale 3): The Working Group recommends reserving at the top level Special-Use Domain Names through the procedure described in IETF RFC 6761. -- Question: How did this recommendation get here? This seems to bypass all of ICANN’s checks and balances. ACTION ITEM: Change to “The Working Group acknowledges…” and add reference to the MOU in the rationale. Recommendation xx (rationale 4): The Working Group recommends updating Specification 5 of the Registry Agreement (Schedule of Reserved Names) to include the measures for second-level Letter/Letter Two-Character ASCII Labels to Avoid Confusion with Corresponding Country Codes adopted by the ICANN Board on 8 November 2016. ACTION ITEM: Change to “second-level Letter/Letter Two-Character ASCII Labels”. Rationale for Recommendation xx (rationale 2): The Working Group considered that Public Technical Identifiers (PTI) was incorporated in August 2016 as an affiliate of ICANN with the primary responsibility of operating the IANA functions. Terms associated with PTI are not included in the list of unavailable/reserved names from the 2012 round because PTI had not yet been established at the time the list was developed. The Working Group recommends that for subsequent procedures, strings “PTI”, “PUBLICTECHNICALIDENTIFIER”, and “PUBLIC TECHNICALIDENTIFIERS” should be reserved and unavailable for delegation at the top level. ACTION ITEM: Only note reservation of acronym “PTI”. c. 2.2.4 Different TLD Types (p 7) Recommendation xx: The Working Group recognizes that there may be circumstances where it makes sense to have differential treatment for an application based on either the type of string, the type of applicant, or the registry focus. Such differential treatment may apply in one or more of the following elements of the new gTLD Program: Applicant eligibility; Application evaluation process/requirements; Order of processing; String contention; Objections; Contractual provisions. ACTION ITEM: Change in the first sentence from “type of applicant” to “type of application” and “or the registry focus” to “or the applicant type”. ACTION ITEM: Add footnote where there are defined terms, such as “Community Based” and “Geographic Names”. Implementation Guidance xx: Other than the types listed in Recommendation xx, the WG believes that creating additional application types should only be done under exceptional circumstances and should be done via agreement by the ICANN community. Creating additional application types, string types, or applicant types should be done solely when differential treatment is warranted and is NOT intended to validate or invalidate any other differences in applications. ACTION ITEM: Change the first sentence to “Other than the types listed in Recommendation xx, the WG believes that creating additional application types should only be done under exceptional circumstances and should be done via agreement by the ICANN community.” Re: Predictability Framework -- Can this phrase be bracketed? -- There was agreement that there should be a framework, just not on what will go into that framework. -- It's possible the Predictability Framework could address an issue if GNSO Council agrees it would be more expeditious. GNSO Council can always decline to use the Predictability Framework using existing GNSO procedures for PDP, EPDP, Input and Guidance.

Note

Notes/ Action Items

Actions:

2.8.2 Post-Delegation Dispute Resolution Procedures

ACTION ITEM: Add a footnote that there is another rights protection mechanism -- the TM-PDDRP -- that is being reviewed by the RPMs PDP WG.

ACTION ITEM: Change the name “Post-Delegation Dispute Resolution Procedures” to “Registry Commitments Dispute Resolution Process”.

ACTION ITEM: Clarify that the PICDRP applies to both mandatory PICs and RVCs.

2.7.1 Reserved Names:

Affirmation xx (rationale 1):

ACTION ITEM: Insert a link in a footnote to the AGB where the reserved names are listed.

ACTION ITEM: Double check to see whether it is necessary to add text noting that the reserved names list has been modified.

Recommendation xx (rationale 3):

ACTION ITEM: Change to “The Working Group acknowledges…” and add reference to the MOU in the rationale.

Recommendation xx (rationale 4):

ACTION ITEM: Change to “second-level Letter/Letter Two-Character ASCII Labels”.

Rationale for Recommendation xx (rationale 2):

ACTION ITEM: Only note reservation of acronym “PTI”.

2.2.4 Different TLD Types:

Recommendation xx:

ACTION ITEM: Change in the first sentence from “type of applicant” to “type of application” and “or the registry focus” to “or the applicant type”.

Notes:

Updates to Statements of Interest: No updates provided.

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

WG Review of Final Report Draft Recommendations: See: https://community.icann.org/x/JDKJBw

-- Includes comments on the first Package of Report topics.

-- Second package will be released on 23 April:

2.10.2 Registrar Non-Discrimination / Registry/Registrar Standardization

 2.5 Registrar Support for New gTLDs

 2.11.1 Registry System Testing

 2.12.1 TLD Rollout

 2.12.3 Contractual Compliance 

-- Note that some recommendations on metrics have been removed. These will be put in a separate section on key metrics and service levels.

-- Question: How will comments be addressed? Answer: We will incorporate the proposed new language and dedicate time at meetings to discuss them. If there is agreement then they will be incorporated, if not then they won’t.

-- There weren’t many comments received on the first package.

-- 04 May will be the next 120-minute meeting.

-- 30 April we will talk about Name Collisions and we’ve invited the Chairs of the NCAP; Jim Galvin, Matt Thomas, and Matt Larson from OCTO.

a. 2.8.2 Post-Delegation Dispute Resolution Procedures

ACTION ITEM: Add a footnote that there is another rights protection mechanism -- the TM-PDDRP -- that is being reviewed by the RPMs PDP WG.

-- Dispute Policies is a good substitution for Dispute Resolution Procedures. But I do not see the difference between Post-Delegation and After Delegation. It means the same, and at least legally, it is usual to use the words “post” and “ante” for after and before.

-- Need to reference the Registries voluntary commitments -- and maybe call it the Registry Commitments Dispute Resolution Process.

-- We definitely need to distinguish between mandatory PICs and Registry Voluntary Commitments.

-- Note that in the Registry Commitments section there is this Implementation Guidance xx (rationale 5): The Public Interest Commitment Dispute Resolution Process (PICDRP) and associated processes should be updated to equally apply to RVCs.

-- Helpful to differentiate between the two types of PICs -- voluntary versus mandatory -- especially for the public.

-- We could still call it the PICDRP would apply to RVCs. We could leave it as PICDRP.

-- Important to specify that PICDRP covers all registry commitments - both mandatory PICS and RVCs.

ACTION ITEM: Change the name “Post-Delegation Dispute Resolution Procedures” to “Registry Commitments Dispute Resolution Process”.

ACTION ITEM: Clarify that the PICDRP applies to both mandatory PICs and RVCs.

b. 2.7.1 Reserved Names (p 40)

Affirmation xx (rationale 1): The Working Group supports continuing to reserve as unavailable for delegation those strings at the top level that were considered Reserved Names and were unavailable for delegation in the 2012 round.

ACTION ITEM: Insert a link in a footnote to the AGB where the reserved names are listed.

ACTION ITEM: Double check to see whether it is necessary to add text noting that the reserved names list has been modified.

Recommendation xx (rationale 3): The Working Group recommends reserving at the top level Special-Use Domain Names through the procedure described in IETF RFC 6761.

-- Question: How did this recommendation get here? This seems to bypass all of ICANN’s checks and balances.

ACTION ITEM: Change to “The Working Group acknowledges…” and add reference to the MOU in the rationale.

Recommendation xx (rationale 4): The Working Group recommends updating Specification 5 of the Registry Agreement (Schedule of Reserved Names) to include the measures for second-level Letter/Letter Two-Character ASCII Labels to Avoid Confusion with Corresponding Country Codes adopted by the ICANN Board on 8 November 2016.

ACTION ITEM: Change to “second-level Letter/Letter Two-Character ASCII Labels”.

Rationale for Recommendation xx (rationale 2): The Working Group considered that Public Technical Identifiers (PTI) was incorporated in August 2016 as an affiliate of ICANN with the primary responsibility of operating the IANA functions. Terms associated with PTI are not included in the list of unavailable/reserved names from the 2012 round because PTI had not yet been established at the time the list was developed. The Working Group recommends that for subsequent procedures, strings “PTI”, “PUBLICTECHNICALIDENTIFIER”, and “PUBLIC TECHNICALIDENTIFIERS” should be reserved and unavailable for delegation at the top level.

ACTION ITEM: Only note reservation of acronym “PTI”.

c. 2.2.4 Different TLD Types (p 7)

Recommendation xx: The Working Group recognizes that there may be circumstances where it makes sense to have differential treatment for an application based on either the type of string, the type of applicant, or the registry focus. Such differential treatment may apply in one or more of the following elements of the new gTLD Program: Applicant eligibility; Application evaluation process/requirements; Order of processing; String contention; Objections; Contractual provisions.

ACTION ITEM: Change in the first sentence from “type of applicant” to “type of application” and “or the registry focus” to “or the applicant type”.

ACTION ITEM: Add footnote where there are defined terms, such as “Community Based” and “Geographic Names”.

Implementation Guidance xx: Other than the types listed in Recommendation xx, the WG believes that creating additional application types should only be done under exceptional circumstances and should be done via agreement by the ICANN community. Creating additional application types, string types, or applicant types should be done solely when differential treatment is warranted and is NOT intended to validate or invalidate any other differences in applications.

ACTION ITEM: Change the first sentence to “Other than the types listed in Recommendation xx, the WG believes that creating additional application types should only be done under exceptional circumstances and should be done via agreement by the ICANN community.”

Re: Predictability Framework

-- Can this phrase be bracketed?

-- There was agreement that there should be a framework, just not on what will go into that framework.

-- It's possible the Predictability Framework could address an issue if GNSO Council agrees it would be more expeditious. GNSO Council can always decline to use the Predictability Framework using existing GNSO procedures for PDP, EPDP, Input and Guidance.

...

Content

Space Tools

Versions Compared

Old Version 8

New Version Current

Key