[Gnso-newgtld-wg] New gTLD Subsequent Procedures PDP WG Consensus Call - Closes Friday, 08 January 2021 at 23:59 UTC

[Aikman-Scalese, Anne]

Dear Jeff, Cheryl, WG Team Members and Staff,
Please see below my response to the Consensus Call on the Final Report, submitted with many thanks to Leadership and ICANN Staff for their tenacity in this effort:

In general, I support the Recommendations, Affirmations, and Implementation Guidance contained in the Final Report and am registering that support in relation to the topics not specifically addressed below.  Having said that, I believe the Working Group should have spent more time addressing the Recommendations of the CCT-RT.  In particular, in relation to 9.15 of the Final Report, I believe the Working Group should have made a formal Recommendation to GNSO Council to undertake an EPDP in relation to DNS Abuse.  Failure to make that recommendation simply delayed policy work that is clearly necessary.

In some cases, I summarize specific areas of support in anticipation of expressions of non-support from other WG members.  For certain recommendations which I do not support, the Recommendation or Implementation Guidance is referred to by topic and number.

Topic 2: Predictability Framework.  Given that the SPIRT cannot make policy and is subject in all proceedings to GNSO Council mechanisms for handling issues, I strongly support the proposed Predictability Framework.  I believe that open participation following the same rules as IRT representation on the SPIRT is critical.  Public comment confirmed that the community supports a “Standing IRT”.  Although Leadership took the view that GNSO Council might vary the structure of the SPIRT to limit its numbers, full participation by the wider community is critical to the success of this new Framework and invitations should be issued to all members of the Sub Pro Working Group and the Sub Pro IRT as codified in Annex E to the Final Report, Item 1.c. under the heading “SPIRT Chartering, SPIRT Recruitment”.  As stated in Topic 2 d. of the Final Report, “The Working Group therefore agreed that the SPIRT is needed to utilize the Predictability Framework and accordingly has provided detailed guidance in Annex E regarding the establishment of the structure.” (Emphasis mine.)

Topic 9: Registry Voluntary Commitments/Public Interest Commitments.  I strongly support the system of PICS and RVCs adopted in the Final Report.  I subscribe to the IPC informal position submitted to the Sub Pro list on this topic (and pasted below) which underlines why such PICs and RVCs are not outside ICANN’s powers under the ByLaws.  I support enforcement of mandatory PICs within ICANN and enforcement of RVCs by an independent third party Dispute Resolution Provider.  In this manner, ICANN can avoid even the appearance of content regulation.  An important part of the Recommendations is that RVCs are always subject to public comment.  I would not support a system of RVCs which are not subject to public comment.  All PICs and RVCs should be included in the applicable Registry Agreement.

IPC Informal Position on PICs/RVCs as submitted to the Sub Pro list pursuant to Leadership’s request for input:

“1. ICANN can enter into and enforce PICS in service of its Mission.   1.1 (d) B (iv) “(iv) ICANN shall have the ability to negotiate, enter into and enforce agreements, including public interest commitments, with any party in service of its Mission.”

2. ICANN is not “imposing” rules and restrictions on parties by acceptance of PICs and RVCs.  RVCs don’t constitute “regulation” of any type, much less content regulation.  (refer to history of Accountability Workstream 1 ).  The ByLaws provision re “imposing” rules and restrictions in 1.1 (c)  states as follows: . (c) ICANN shall not regulate (i.e., impose rules and restrictions on) services that use the Internet’s unique identifiers or the content that such services carry or provide, outside the express scope of Section 1.1(a). For the avoidance of doubt, ICANN does not hold any governmentally authorized regulatory authority.  This language makes it clear that ICANN does not intend to act as a government regulator.  It does not prohibit adoption and enforcement of PICs.

The ByLaws clearly state that all previously-adopted PICs are in force and may be renewed going forward. See 1.1 (d) which states as follows:

(d) For the avoidance of doubt and notwithstanding the foregoing:
(i) the foregoing prohibitions are not intended to limit ICANN’s authority or
ability to adopt or implement policies or procedures that take into
account the use of domain names as natural-language identifiers;
(ii) Notwithstanding any provision of the Bylaws to the contrary, the terms
and conditions of the documents listed in subsections (A) through (C)
below, and ICANN’s performance of its obligations or duties
thereunder, may not be challenged by any party in any proceeding
against, or process involving, ICANN (including a request for
reconsideration or an independent review process pursuant to Article
4) on the basis that such terms and conditions conflict with, or are in
violation of, ICANN’s Mission or otherwise exceed the scope of
ICANN’s authority or powers pursuant to these Bylaws (“Bylaws”) or
ICANN’s Articles of Incorporation (“Articles of Incorporation”):
(A)
(1) all registry agreements and registrar accreditation
agreements between ICANN and registry operators or
registrars in force on [1 October 2016]1, including, in
each case, any terms or conditions therein that are
not contained in the underlying form of registry
agreement and registrar accreditation agreement;
(2) any registry agreement or registrar accreditation
agreement not encompassed by (1) above to the
extent its terms do not vary materially from the form of
registry agreement or registrar accreditation
agreement that existed on [1 October 2016];
(B)any renewals of agreements described in subsection (A) pursuant
to their terms and conditions for renewal;

The fact that even voluntary PICS may be renewed going forward confirms without a doubt that they are not outside of ICANN’s power under the new ByLaws.  Thus, adoption and enforcement of voluntary PICs (RVCs) is not ultra vires.  Unfortunately the recently proposed “guardrails” around the adoption of voluntary PICs and Registry Voluntary commitments would in fact make ICANN a regulator of content, making ICANN the judge of a Registry’s Human Rights compliance and making ICANN (rather than the Registry) the arbiter of whether a particular RVC addresses content.  In other words, the guardrails proposed increase the danger that ICANN would be acting as a content regulator.

3. No revision to the ByLaws is necessary for ICANN to accept and approve the PICs and RVC policy developed by the WG.  The ICANN ByLaws clearly state in the Mission section that the PDP process acts as a “guiding light” in  the development of policy that relates to ICANN’s Mission.  Current ByLaws Section 1.1. (a) states:
Specifically, ICANN:
(i) Coordinates the allocation and assignment of names in the root zone
of the Domain Name System (“DNS”) and coordinates the
development and implementation of policies concerning the
registration of second-level domain names in generic top-level
domains (“gTLDs”). In this role, ICANN’s scope is to coordinate the
development and implementation of policies:
• For which uniform or coordinated resolution is reasonably
necessary to facilitate the openness, interoperability, resilience,
security and/or stability of the DNS including, with respect to
gTLD registrars and registries, policies in the areas described in
Annex G-1 and Annex G-2; and
• That are developed through a bottom-up consensus-based
multistakeholder process and designed to ensure the stable and
secure operation of the Internet’s unique names systems.


During its deliberations, the Sub Pro Working Group majority implicitly determined that the recommended system of PICs and RVCs is reasonably necessary to facilitate the openness, resilience, and stability of the DNS.   The policies developed are perfectly aligned with the scope of the Mission and do NOT constitute governmental content “regulation”.  In fact, PICs and RVCs are not about content at all. They are about resolving potential disputes that might otherwise lead to litigation and/or a chilling effect of preventing the launch of a TLD.  This means that the system of PICs and RVCs will serve ICANN’s Mission to preserve and support security, stability, and resiliency.  Furthermore,  all voluntary PICs and RVCs will be open for public comment and super transparent.  ICANN has the power and even a duty to enforce PICs that shore up security, resiliency, and stability as determined via PDP recommendations unless such recommendations are voted down by a 2/3 majority of the Board.  In addition, if RVCs are not entered into and enforced within the ICANN system, transparency is defeated because back room deals can still be made as a matter of private contract law. PICs and RVCs keep these commitments out in the open.

4.  If ICANN is concerned about the burden of enforcement, it can refer RVCs to an independent panel that ICANN does not pay and cannot override, just like UDRP.  The RVC-DRP can be created in a way to allow ICANN to step back from any ICANN.org determination re RVC compliance.”

Topic 12 – Applicant Guidebook.   Recommendation 12.9  - Rather than the two months period specified for AGB versions other than English, the Applicant Guidebook should be available in all 6 UN languages at the same time, i.e. four(4) months prior to the commencement of the opening of the window for applications.

Topic 23 -  Closed Generics.  I agree that the WG members did not reach Consensus on this topic.  I disagree with WG members who maintain that the “status quo” is no prohibition on Closed Generics.  After the 2012 implementation, applicants for Closed Generics were permitted to convert to open registries or to withdraw applications with refunds pursuant to Board Resolution.  I support the proposal made by Greg Shatan in the December 10, 2020  WG call (at 1 hour 7 minutes into the call) to allow applications for Closed Generics but to “suspend” such applications subject to further policy work in the appropriate forum, e.g. EPDP.  In this regard, it would be helpful for the ICANN Board to specify whether it intends to accept standing GAC Advice to the effect that a “Closed Generic” should serve a public interest goal.  Such guidance would assist the GNSO Council in constructing a Charter for an EPDP.  Here it is important to note that a finding that a particular Closed TLD “serves a public interest goal” does not need to be equal to a finding that a particular Closed TLD is “in the Global Public Interest”.  The two standards are distinguishable and elements to establish the status of serving a public interest goal are ascertainable.  Specific questions for evaluation of this status are suggested beginning on page 104 of the December 22 version of the Final Report.

It should also be noted that if this Closed Generic topic is not resolved by adoption of policy prior to the opening of the next application window, it is certain there will be applications for Closed Generics by applicants who will be relying on the new policy contained in Implementation Guidance 3.4 that prohibits subsequent applications for the same string if any prior application for that string remains unresolved. This means that a future application for a Closed Generic could effectively block a subsequent round application for an Open Generic TLD for the same string.  Such a result would violate the Principle of Applicant Freedom of Expression which has been affirmed by the Working Group as discussed in Topic 10.

Topic 29 – Name Collisions.  I strongly support Recommendation 29.1 stating that ICANN “must” have ready a mechanism to evaluate the risk of name collisions.  The portion of the recommendation that specifies the timing as  “in the evaluation process as well as during the transition to the delegation phase” is ill-advised as the mechanism should be developed before the application window opens.  Such a “gating mechanism” will assist applicants in knowing whether or not to go to the trouble and expense of preparing full blown application.  I DO NOT SUPPORT Affirmation 29.2 which affirms continued use of the current Name Collision Occurrence Management framework in relation to a new round of gTLDs “unless and until the ICANN Board adopts a new mitigation framework”.  The harm from name collisions is not limited to “human-life threatening conditions”.  Pursuant to SSAC Advice, the Board should properly assess name collision risk before adding TLDs to the root.  Accordingly, the Board should await the outcome of the NCAP work and SSAC Advice on questions posed by the Board on this topic and should adopt a new Name Collision Occurrence Management Framework before accepting applications for the next round of new gTLDs.  This will avoid unnecessary expense and work for applicants and for ICANN staff which could proliferate AFTER the application window opens if the appropriate name collision work is not done prior to that time.

Topic 34 – Community Applications.  I strongly support the recommendations and implementation guidelines adopted by the Working Group on this Topic.  Special thanks to the ALAC, in particular to ALAC rep Justine Chew, and to Jamie Baxter for their contributions to these improvements.

Topic 35 – Auctions: Mechanisms of Last Resort/Private Resolution of Contention Sets.  Regarding Recommendation 35.4, in connection with the Implementation phase, applications designated as Specification 13 Brand applications should not be subject to the “Last Resort Sealed Bid” process unless the brand applicant retains all rights to file a Legal Rights Objection and to negotiate for Registry Voluntary Commitments in relation to the winning bidder.  This is due to the fact that after String Similarity Evaluation, no other information regarding the applications may be shared prior to submitting the sealed bid.  For trademark holders/brand owners, the intended use and actual use of the TLD is very important, as are possible restrictions via RVCs to limit the potential injury to brands which may be posed by the ownership and operation of the TLD by a third party other than the brand owner.  Forcing brand applicants to file Objections and submit sealed bids without full information regarding the application that matches the brand encourages litigation (with its corresponding expense for all parties and delays in delegation).

Respectfully submitted,
Anne Aikman-Scalese
8 January, 2021

From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces at icann.org<mailto:gnso-newgtld-wg-bounces at icann.org>> On Behalf Of Emily Barabas
Sent: Tuesday, December 22, 2020 9:30 AM
To: gnso-newgtld-wg at icann.org<mailto:gnso-newgtld-wg at icann.org>
Subject: [Gnso-newgtld-wg] New gTLD Subsequent Procedures PDP WG Consensus Call - Closes Friday, 08 January 2021 at 23:59 UTC

[EXTERNAL]
________________________________
Dear WG members,

On behalf of the WG Co-Chairs, and as discussed during the WG meeting on Thursday, 17 December, this email is to notify you of the opening of the online Consensus Call on the WG Outputs (i.e., Affirmation, Affirmation with Modification, Recommendation, Implementation Guidance, and No Agreement) of the New gTLD Subsequent Procedures GNSO Policy Development Process (PDP). Pursuant to the content freeze on 18 December, please see the attached PDF of the Outputs and contextual language, which has received a handful of non-substantive updates (for a redline version that shows the minor edits made since 18 December, please see the wiki<https://community.icann.org/display/NGSPP/h.+Final+Report+Drafting>). WG members who wish to familiarize themselves with the steps involved and the various levels of consensus applicable to GNSO PDP recommendations can refer to the recording of the 17 December meeting<https://community.icann.org/display/NGSPP/2020-12-17+New+gTLD+Subsequent+Procedures+PDP> where the Consensus Call process was described.

This Consensus Call opens today, Tuesday, 22 December 2020 and closes on Friday, 08 January 2021 at 23:59 UTC.  Per the GNSO Working Group Guidelines [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/file/field-file-attach/annex-1-gnso-wg-guidelines-24oct19-en.pdf__;!!PtGJab4!rNJ7mR-y3NiOaoAVdoJAaixwM1dqZ9IzY_6ZGh-d2rURZLU7eQqaDXkxDxY267kIUfu4bau_tQ$>, WG members are requested to indicate via reply to this list whether they support, or do not support, the Outputs. If a WG member does not respond this will be taken as support.

The Outputs are largely being presented in a single package and should be considered as an integrated set of Outputs, which are the result of many years of WG discussions and input received. This includes not only the work of the WG, but also the comments we received to Constituency Comments 1 & 2, the work of Work Tracks 1-5, comments to the Initial Report and the two Supplemental Initial Reports, and the comments to the Draft Final Report.  Therefore, there will likely be Outputs that you believe are imperfect, so the Co-Chairs encourage you to consider the Outputs in the aggregate. Even if given that context, you still believe there are Outputs that you do NOT support, please specifically identify the Specific Recommendations and/or Implementation Guidance within the Outputs that you do cannot support and why.

For the purposes of this Consensus Call, the Outputs are being organized accordingly:

  *   Topic 9: Registry Voluntary Commitments / Public Interest Commitments;
  *   Topic 23: Closed Generics;
  *   Topic 34: Community Applications/CPE;
  *   Topic 35: Auctions: Mechanisms of Last Resort / Private Resolution of Contention Sets; and
  *   All other Outputs in the report.

As noted on the 17 December 2020 WG call, the Consensus Call is being issues to Individual Working Group members (and not to the Constituencies, Stakeholder Groups, Supporting Organizations, and/or the Advisory Committees in which such individuals participate).  Therefore, WG members will be assumed to be responding to the consensus call on their own behalf unless they explicitly state in their response that they are responding on behalf of their group/organization. Following the close of the Consensus Call, the WG Co-Chairs will meet on Monday, 11 January 2021 to review the responses from the WG members and determine the Consensus Designations for the Outputs.  The WG Co-Chairs will post the results of their determination to the WG email distribution list on January 11, 2021.

On 12 January 2021 at 20:00 UTC, the Working Group will have its next and hopefully final call to discuss any questions or comments to the Consensus Designations.  Calendar invites have been sent out to Working Group members.  Although the meeting is scheduled for 120 minutes, WG leadership will stay on the call until all questions have been addressed. Working Group members will then have until 13 January 2021 at 23:59 UTC to object to the Consensus Call designations. The final Consensus Call designations shall then be included in the Final Report.

Finally, to the extent they are needed, WG members may begin working on minority statements now and through the Consensus Call period, with the ultimate due date of 18 January 2021.

Kind regards,
Steve, Julie and Emily on behalf of the SubPro Leadership Team



________________________________

This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20210108/23ad8205/attachment-0001.html>