Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Info

PROPOSED AGENDA


  1. Review Agenda/Updates to Statements of Interest
  2. Review draft Final Report Public Comments – to prepare see the links to the Public Comment Review Tool on the wiki at: [docs.google.com]https://community.icann.org/display/NGSPP/h.+Published+Draft+reports and review the following topics and comments:

Topic 18: Terms and Conditions [docs.google.com]

Topic 22: Registrant Protections [docs.google.com]

Topic 7: Metrics and Monitoring [docs.google.com]

Topic 23: Closed Generics [docs.google.com]

       3. AOB

BACKGROUND DOCUMENTS




Info
titleRECORDINGS

Audio Recording

Zoom Recording

Chat Transcript 

GNSO transcripts are located on the GNSO Calendar


Tip
titlePARTICIPATION

Attendance

Apologies:  Dial out: Cheryl Langdon-Orr, Harold Arcosnone


Note

Notes/ Action Items


Action Items:

Topic 18: Terms and Conditions


Row 13 – RySG and Row 14 -- The Galway Strategy Group re: Reference other relevant recs in this section

ACTION ITEM: Check to make sure that mentions of changes to Terms and Conditions in other sections are cross-referenced in Section 18.


Row 19 – ICANN Board Re: ““[u]nless required by specific laws,ICANN Board members’ fiduciary duties, or the ICANN Bylaws, ICANN must only reject an application if done so in accordance with the provisions of the Applicant Guidebook. In the event an application is rejected, ICANN org must cite with specificity the reason in accordance with the Applicant Guidebook, or if applicable, the specific law and/or ICANN Bylaws for not allowing an application to proceed. This recommendation constitutes a revision to Section 3 of the Terms and Conditions from the 2012 round.””

ACTION ITEM: Double check against the GAC language.  Revise to ensure language also is consistent with the Bylaws.


Topic 22: Registrant Protections


Row 11 – ALAC re: GDD should publish more detail/explanation on 5 critical registry functions triggering EBERO.

ACTION ITEM: Add to Metrics Section.


Topic 7: Metrics and Monitoring


Row 13 – RySG re: Suggested metrics

ACTION ITEM: Add the metrics suggested.


Row 16 – ALAC

ACTION ITEM: Include ALAC suggested metrics on EBERO.


Row 17 -- ARTICLE 19 re: Metrics and monitoring should be in line with data protection rules and privacy rights.

Leadership Comments: I think we can add a general disclaimer that this be adhered to.

ACTION ITEM: Add a general disclaimer that metrics and monitoring should be in line with data protection rules and privacy rights.


Topic 23: Closed Generics

ACTION ITEM: Leadership will meet to discussion and come back with some suggestions for how we go from here.


Notes:

  1. Updates to Statements of Interest: None provided.

  

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 18: Terms and Conditions


-- Most commenters agreed with the output as written.


Row 13 – RySG and Row 14 -- The Galway Strategy Group re: Reference other relevant recs in this section

ACTION ITEM: Check to make sure that mentions of changes to Terms and Conditions in other sections are cross-referenced in Section 18.


Row 19 – ICANN Board

Leadership Comments:  The purpose of our changes are to ensure predictability to the process. The Reservation of Rights for the ICANN to reject any application for any reason essentially obliterates all of the improvements added to the program to ensure there is predictability in the process. If there are certain reasons for being able to reject an application that are not enumerated, then please let us know what you believe is missing.

Re: ““[u]nless required by specific laws, ICANN Board members’ fiduciary duties, or the ICANN Bylaws, ICANN must only reject an application if done so in accordance with the provisions of the Applicant Guidebook. In the event an application is rejected, ICANN org must cite with specificity the reason in accordance with the Applicant Guidebook, or if applicable, the specific law and/or ICANN Bylaws for not allowing an application to proceed. This recommendation constitutes a revision to Section 3 of the Terms and Conditions from the 2012 round.””

ACTION ITEM: Double check against the GAC language.  Revise to ensure language also is consistent with the Bylaws.


Discussion:

-- Question: Does the language of the recommendation parallel the GAC language? 

-- We didn’t cite the language from the Bylaws on the exercise of fiduciary duties.  The purpose of this provision is not to give applicants grounds to allege that the appeal process didn’t meet their satisfaction, but rather to state the Working Group's view that a covenant not to sue in favor of ICANN is only palatable if the Appeals / Challenge mechanism (as described in Section 32 is actually implemented). If there is language ICANN legal would like to add to make this clear in the actual Ts and Cs, and that language is consistent with the intent of the Working Group, then we would encourage ICANN to run that by the IRT.


Row 20 – ICANN Org re: Considerations regarding covenant not to sue. Clarify recs regarding refunds.

Leadership Comments: 1. See above. 2. Discuss Refund issue with WG


Re: “applicants must be allowed some type of refund if they decide to withdraw an application because substantive changes are made to the AGB or program processes and such changes have, or are reasonably likely to have, a material impact on applicants.”

Discussion:

-- If it is a material change and impacts the applicant in a significant way then there should be a full refund.

-- Wonder about the mechanism and logistics of a full refund – how to determine the threshold.

-- Maybe we need a benchmark of what a material change would be.  Could be if a change is made to the AGB that makes an applicant ineligible then it should get a full refund.

-- It's important to acknowledge that the investment of applying for a new gtld/s is more than just the $185k application fee.

-- Keep it as is but specify that it is up to a full refund.


Topic 22: Registrant Protections


Row 11 – ALAC re: GDD should publish more detail/explanation on 5 critical registry functions triggering EBERO.

ACTION ITEM: Add to Metrics Section.

 

Row 13 – ICANN Board Re: The Board encourages the PDP WG to provide more details in its rationale and to ensure there are no hypothetical cases in which an EBERO might be appropriate. In addition, the Board encourages the PDP WG to consider the potential impact on end users and consumers in the event of a short-term or long-term technical or business failure of a .BRAND TLD.


Discussion:

-- Think we should have language about EBERO for .BRANDs.

-- Not sure how a .BRAND shutting down would impact anyone except .BRAND.

-- There could be technical reasons that a .BRAND registry would need to shut down.

-- I also believe this is firmly about registrant protection.  It's about ensuring that those who have built their digital presence on a domain within a TLD that fails, do not lose that digital presence.  Recognizing the cost to transition to a new domain is not insubstantial.

-- What about help for a .BRAND that is having technical problems?

-- This is the Brand's problem.  It shouldn't be forced to have this protection.  This is help that is not wanted.

-- EBERO is not a protection for a TLD - it is a death of a TLD, and just zombie copy of the last state of the TLD.


Row 14 – ICANN Org re: Concerns about proposed COI exemptions

Leadership Comments: Noted for 22.5, 22.6, and 22.7


Topic 7: Metrics and Monitoring


Row 13 – RySG re: Suggested metrics

Leadership Comments: Suggest inclusion?

ACTION ITEM: Add the metrics suggested.


Row 14 – ALAC

Leadership Comments: Noted. Some of these have been discussed in other contexts


Row 15 – ALAC

Leadership Comments: These metrics were already incorporated into the Applicant Support Program section.


Row 16 – ALAC

ACTION ITEM: Include ALAC suggested metrics on EBERO.


Row 17 -- ARTICLE 19 re: Metrics and monitoring should be in line with data protection rules and privacy rights.

Leadership Comments: I think we can add a general disclaimer that this be adhered to.

ACTION ITEM: Add a general disclaimer that metrics and monitoring should be in line with data protection rules and privacy rights.


Row 18 – ICANN Org

Leadership Comments: Need to explore re: Recommendation 7.3: “ICANN org confirms that the PDP WG recommends that subsequent procedures phases include metrics, service level agreements (SLA), and monthly reporting. We understand that the phases listed in the Recommendation are examples and not a requirement to be used, as the names of phases may change in subsequent rounds.” Noted.


Topic 23: Closed Generics


See Closed Generics Proposals included in the draft Final Report: https://community.icann.org/display/NGSPP/Proposals+Included+in+Draft+Final+Report

-- In general, very little support for the two extremes (all all/restrict all).

-- Fair number of comments on closed generics that support the public interest goal.

-- ICANN would probably not want to be involved in a public interest test.

-- Legitimate public interest goal is difficult to define.  But also don’t think this WG would agree to allow Closed Generics without restrictions.

-- Don’t see how we can get agreement on the three proposals.

-- GAC is not likely to withdraw its comments.

-- Don’t see we can come to something that is acceptable.  Banning Closed Generics might be the only option.

-- One thing the Board can do is reject the GAC Advice on the basis that a PDP WG has discussed this and come up with a number of proposals – there has been community discussion without a unified position.

-- IPC and BC had concerns in their comments about why it wasn’t acceptable for the WG to have a non-recommendation.

-- If we cannot define “global public interest” and make it predictable, then we can’t recommend Closed Generics.

-- 1. We need to be responsive – may want to be more pointed than just an objective summary.  Need to highlight why this was difficult – defining the “global public interest” in this context.  2. Determine whether we have consensus against unfettered Closed Generics.  Recommendation could be that Closed Generics are suspended.  A ban seems to go beyond what we could agree to.

-- It certainly is OK to put the details of non-agreement to change the 2012 AGB in the Deliberations section, but not to pretend there are levels of agreement that might rise to a rough consensus that would convert one of the 3 non-agreed options into a Recommendation.

-- Some support for a recommendation of suspension, but some don’t support.

-- Do not support an indefinite suspension. This is one of the most active PDP WGs with consistent attendance. Discussing this for another two to three years isn't going to change much.

-- We can also recommend that this be worked on and a permanent result should be arrived at.

-- We have no way to understand the harm. What about rather than an suspension, a number of closed generics be allowed in order to better understand whether the perceived harm is real or are there benefits to Internet users and innovation in the domain name space.

-- The fallback on this topic could just as easily be 2012 implementation versus the 2012 silence on the topic.  In all other areas, 2012 IMPLEMENTATION is the fallback.

-- Wonder whether it’s possible to agree to allow Closed Generics on a case-by-case basis and for them to be challenged.

-- There is a difference between a "Closed Generic that serves a Public Interest" versus determining that a Closed Generic is "in the Global Public Interest".  Further policy development efforts should be focused on the former.

-- Make it clear that we are not recommending a ban in the form of a suspension – that we want it to be dealt with.

ACTION ITEM: Leadership will meet to discussion and come back with some suggestions for how we go from here.


...