Dear all,

Please find below notes from the call on 6 August 2019 at 03:00 UTC. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which are posted at: https://community.icann.org/x/SaujBg

Kind regards,

Emily

Notes and Action Items

1. Welcome and Updates to Statements of Interest

No Updates

2. Review of summary document: (continued)

Terms and Conditions

Attendance for this meeting is heavily registry focused. Other members who are unable to attend the call should review the notes/transcript/recording and provide input over the mailing list.
Note that Jeff has provided some small draft edits to the document in redline.
Review of background documents, policy goals, and high level agreements.
Jeff suggested small change to the high level agreement - The commenters generally supported the idea that unless required under specific laws or the ICANN Bylaws, ICANN should only be permitted to reject an application if done so in accordance with the provisions of the Applicant Guidebook. This originally said, “in accordance with the Terms and Conditions.” As ICANN Org noted, the logic is a bit circular with the original language. The proposed edit corrects this.
On the second high level agreement, Jeff suggested adding “with specificity” to indicate that applicants should receive a detailed explanation.
One WG member noted that due to anti- money laundering laws a short contract is needed to pay the application fee. Terms and conditions should be part of it or referenced there. It is also a recommendation of the Financial Action Task Force (intergovernmental organization).
Question by WG member – If the covenant not to sue is removed, do we not recommend an appeals mechanism? Response – this will be discussed when we reach the section on the covenant not to sue.
Note on the intersection of high-level agreement 4 with the topic of Predictability – the issue of whether changes can be made and how those changes can be made is covered under Predictability. The issue of recourse when certain changes are made is covered under this topic.
Assumption underlying the final high level agreement – the true risk of name collisions will be determined after the application is filed.
Clarification that final high-level agreement indicates that a full refund should be provided because the applicant could not have anticipated the name collision issue.
One member indicated that it is potentially problematic if the AGB is interpreted to mean that a category of terms is not allowed after applications are submitted.
Review of comments about the rejection of an applications only under law, Bylaws, or in accordance with the Applicant Guidebook.
On RySG comment under this topic, participants from the registries will clarify why those specific sections of the AGB were called out. One member recalled that the intention was to limit the universe of changes that would be permitted.
Review of comments advocating for confidentiality if ICANN Org is required to disclose the reason for rejecting the application.
One member expressed support for the Valideus formulation of confidentiality requirements in the comments.
One member did not support confidentiality. Another clarified that the comments speak to confidentiality of ICANN’s evaluation of the application, not issues that are public, such as objections or concerns raised about whole categories of strings. It not necessary put this information out to the public if the application is not going to go forward.
Question raised – what if the reason was kept confidential only if confidential information was included in the reason? Would registries accept that? Response – the registries prefer that the reason is always confidential and are not aware of a justification for disclosure.
It was noted that in the current AGB, if the application does not move forward, that reason is made public.
Participants for the registries will discuss with the RySG and see if there is potential to support the Valideus proposal on confidentiality.
Clarification on the definition of “confidential information” – this refers to the sections of the application that are not public. A member suggested that if this is addressed in the recommendations, the terminology should be defined/explained in a footnote.
Review of comments on the covenant not to sue.
One member stated that there is no indication to form the basis of a belief that the covenant not to sue is legally valid. It was noted that the covenant was upheld in Ruby Glen vs. ICANN, but that was just one court case.
A member asked for background on why the covenant was included in the first place. Response –The justification given was the ICANN needed to include the covenant not to sue as a non-profit organization. ICANN could not subject itself to unlimited liability. Some in the community opposed it.
Review of comments on recourse if substantive changes are made to the Applicant Guidebook or program processes. Review of comments on a refund for applicant if there are substantive changes to AGB or other circumstances. Co-chairs suggested moving these comments to the section on predictability.
Review of additional suggestions to change the Terms and Conditions.
Question regarding ALAC new idea that Terms and Conditions should specify all applicable routes, procedures, costs and timelines for any challenge/appeal mechanism. Should this say “The AGB should specify. . .”?
On the BC new idea that applicants should transparently declare whether they intend to operate the registry, or whether they anticipate selling pending applications to others, the co-chairs noted that this refers to the issue of transferability. The Ts and Cs currently state: "Applicant may not resell, assign, or transfer any of applicant’s rights or obligations in connection with the application."
It was noted that once the registry is past the application phase, this is governed by the Registry Agreement.
Question – for those who supported keeping the covenant, is there understanding that the appeals mechanism includes an independent review? Was that part of the discussion? Response: In the Initial Report, the appeals mechanism is in addition to the Accountability Mechanisms, scope of Accountability Mechanisms are included in the bylaws, but it was recognized that substantive issues were not necessarily covered in the scope of the Accountability Mechanisms. Assumption is that covenant would be ok if there was an additional appeals mechanism.
Concern was raised about the proposed appeal mechanism and that it may be duplicative of the new IRP rule.
Leadership – there appears to be a high-level of support for a limited appeals mechanism that is not a substitute for other Accountability mechanisms. This will be discussed further under a different topic.

Application Queuing, page 2 – See: https://docs.google.com/document/d/1nf8qGP9Y7OYuT0ZvxIgM1fZtNa4Kj8DyhzpmPhEcNGM/edit#

Review of policy goals and high-level agreements.
Note that the RySG supports an initial randomization with a limited opportunity to buy an earlier spot in line, which would be optional.
Clarification provided that the general point of agreement is to keep the system in place as in the 2012 round – there was an option to buy a ticket to participate in a priority draw. All other applications were included in a subsequent draw.
Note that ICANN legal will have to conduct a detailed legal analysis regarding what is possible for application queuing, but that California lottery laws do not change frequently, so it is unlikely that they are different compared to 2012.
Some support in the comments for the idea that numbers could be transferrable. Some other groups opposed this proposal.

Next call is Thursday 8 August at 20:00 UTC