Hello all, The notes, recordings and transcripts for CCWG ACCT meeting #77 - 14 January will be available here: https://community.icann.org/x/HpVlAw A copy of the notes and action items and notes may be found below. Thank you. Kind regards, Brenda Action Items * ACTION ITEM/Conclusion: Becky and David to work on language for carve-out that will be put for discussion on list. * ACTION ITEM/Conclusion: Board to reach out to ASO and come up with proposal. * ACTION ITEM/Conclusion: Board to reach out to RSSAC and come up with proposal. * ACTION ITEM/Conclusion: Get input from NTIA on whether it was meant to be a chapeau and share on list. Notes These high-level notes are designed to help you navigate through content of the call and do not substitute in any way the transcript. Rec 1 Inspection rights - Second reading Board input: Board agrees with inspection right that are limited to accounting books and can be invoked by single SO/AC. They should be a community right and not be reserved to the Sole Designator. The Sole Designator can enforce the right. When invoked, demand should go to and through ICANN i.e. a community process. Giving the Sole Designator an inspection right gives the model an inappropriate change. Text proposal: Paragraph 20: "the CCWG-Accountability recommends including in the ICANN Bylaws the right for SOs or ACs to inspect as outlined in California Corporations Code 6333, although this specific article reference would not be mentioned in the Bylaws." Paragraph 21: "This inspection right is distinct from the Document Information Disclosure Policy (DIDP). While any eligible party can file a request according to the DIDP, Inspection Rights are only accessible to SOs or ACs. The scopes are also different as explained below." "Unlike the exercise of the other community powers, which require community engagement and escalation before initiating a request for action by the EC, the CCWG-Accountability recommends that a petition for inspection be brought directly by a single SO/AC or by multiple SO/ACs through making a written demand on ICANN for the requested materials. If the Board refused or ignored the request, the petitioning SO/AC(s) could then initiate an escalating community decision-making process to enforce demand on the Board requiring community consensus. On Investigation Rights: The Board agrees with the inclusion of an investigatory right, and notes that the language proposed in redline reflects the Board's comments. On DIDP: The Board reaffirms its commitment to addressing improvements to the DIDP in WS2, and thanks the CCWG for the clarification in the document on the differences between the inspection right and the DIDP. Feedback: - It is unclear that there will be an expanded process for DIDP. Is that the case? --> DIDP is not on agenda of recommendation 1. This discussion will take place on Thursday. Conclusion: We will be moving forward with inspection rights section. We will reopen second item - GAC as decisional participant - once we have input from GAC. ---- Rec 2 - Escalation timeline - Second reading Edits include: timeframe lengthened for SO/ACs to make a decision and conference call step removed. Once petition is launched, it will go to Community Forum. This has an impact on threshold and overall timeframe. Rationale for giving additional time is to give more time for SO/ACs to exchange on why they would want power to be used. Extension is not available for ICANN or IANA budget. On timeframe Feedback: - (1) The CF format allows for a "second or third" session if needed - because the CF is the best chance to amicably resolve an issue that makes sense but won't these added sessions need an extension "as appropriate" as 21 days may be inadequate ---> Community Forum might take 1-2 days. Cannot imagine it would but there could be a Community Forum where separate sessions to give a global conversation (e.g. session at 06:00 UTC - 14:00 UTC etc). We have set deadlines for when Forum should be started but may want to set tighter limits for duration of Forum. - (2) Suggest step six get 3 days, not 1 - there may be communication issues or human error. ---> Board will be advised. SO/AC decision will be recording decisions publicly. - (3) Could the "days" specified be limited to week days - remember that holidays vary widely across the globe and August is virtually work-free almost everywhere ---> Intention is not that 21 days would be business days. If we want to extend timeframe, we should have discussion but the days in this document are calendar days. - There is encouragement to socialize other information required before the Community Forum is held. We cannot be too prescriptive on number of days (depending on difficulty of issue). We should allow for flexibility. We should not be too prescriptive on process - when resolution has been found. Feedback: - Use calendar days instead of week. ---> Natural days will be used. - Community Forum is opportunity to resolve differences between community and Board. If there is opportunity for resolution of issues, there will need to be multiple sessions. It is inevitable that there will be multiple sessions. - Escalation timeframe has been issue for some GAC members. How many days did the process have before the changes (at a maximum) and how many days will it have when the changes proposed by Jordan will be inserted? We might be compressing too much. Jumping to the Community Forum needs to be considered with care. Sessions does not mean meeting on same days. We should allow for further deliberations. If Board comes up with new solution/reasoning, we need to go back to our SO or AC. More time is needed for meaningful deliberations. By suppressing conference call, we are diminishing elements of deliberation. ---> In the previous process, we were rushing SO/ACs (conference call within 7 days). By deleting this step, we are saving two decision points. We may want to give timeframe for which discussions should happen. On formal structure, there will be informal discussions going on. We need to juggle community need for dialogue with exercise of powers. - Our objective is to streamline the process. There are discussion steps before the Community Forum. Community will be informed for Community Forum discussion. Feedback: - Unclear that there will be deliberations Board input: The Board will support the community in making reasonable adjustments to the escalation timeframes to support the community's ability to take quick action to exercise its powers, while still having the time it needs to socialize the issues appropriately. Where the community believes that some of the tight timeframes might require adjustment by a matter of days, or have flexibility to simplify some of the steps when broad community support is clear, these are all areas that the Board can support adjusting. As the CCWG works to finalize a revised proposal on this, the Board notes that it would not support an extension of the initial petition phase beyond 30 days, and urges the timelines to be drafted with efficiency and quick action in mind. On thresholds, the Board supports the CCWG modification at Paragraph 62. On Board removal, the Board does not support the change at Paragraph 64. Demonstration of full community support for the exercise of this ultimate power is essential, and the Board does not support a change to lower this threshold. The other areas where this reduced threshold is proposed (blocking budget, fundamental Bylaws changes) do not raise this same concern. A proposed redline of Paragraph 64 to address this concern is: The CCWG-Accountability also recommends that in a situation where use of the community powers of either blocking a budget or approving changes to Fundamental Bylaws, where only four Decisional SOs or ACs participate, and the threshold is set at four in support these two powers will still be validly exercised if three are in support and no more than one objects. The CCWG-Accountability came to this decision after considering the extended escalation process now proposed prior to the use of Community Powers, and to avoid the risk of powers being un-useable (especially the risk of making changes to ICANN's Fundamental Bylaws effectively impossible. Conclusion: We are trying to have a process that is efficient and flexible. Documentation should be exchanged prior to Community Forum. We will continue collecting ideas and refining on the list. We will conclude this item next week. On thresholds Feedback: - If at stage where SO/ACs cannot take action (3 out of 5), we will end up with situation where organization is frozen and Bylaw cannot be changed. If Community Forum is called and no one attends, the Board could act unilaterally past a defined period of time. There needs to be an escape patch. ---> Let's move this concern and suggestion to the list. If it gets traction, we will move it to the plenary. - Disagree with suggestion above. Conclusion: No objection to thresholds proposed in Jordan's revised document. Rec 4 - Budget (IANA) Board input: Paragraph 21: Board is very supportive of text - it addresses concerns. We are properly delivering services. The whole caretaker budget should be embedded in Fundamental Bylaws. 1) e. Board Proposal on ICANN Caretaker Budget. In the event that the process for community power to reject the Operating Plan and Budget is invoked, and after the preceding escalation mechanism (as described in Recommendation #2) has failed to resolve an issue, the rejection is triggered. While the rejection is in effect and being resolved, ICANN needs an operating plan and a budget so that it can continue to operate on a day-to-day basis. The notion of a caretaker Operating Plan and Budget has been defined to address this need. The caretaker budget is in substance a replacement Operating Plan and Budget designed to allow the organization to operate its basic and primary functions, while avoiding "non-indispensable" work during the period of the rejection is in effect. The conceptual definition of the caretaker budget has been formulated, but the more detailed definition of what is "indispensable" or not now must be further documented. The Board accepts the above described approach to the veto process and corresponding caretaker Operating Plan and Budget. The Board also recommends that the caretaker budget approach be embedded in the Fundamental Bylaws, including the responsibility of the CFO to establish the caretaker budget in accordance with the defined approach. The Board's acceptance of this approach is also predicated on the consistency of the implemented solution with the conceptual definition described above. In paragraph between 19 and 20, the caretaker budget would be enacted and details are under development. We can have it in line with paragraph 13. Caretaker budget will be developed in implementation in line with guidelines. Feedback: * Valid points. In favor of Board suggestions on Caretaker Budget. We want to ensure we have alignment with budget power. * Agree with Board suggestions Conclusion: We will be taking Board suggestions on board. ----- Rec 3 Fundamental Bylaws (first reading) Overview of comments/discussion items. Feedback: / Conclusion: We will take on these suggestions for second reading. Rec 4 Scope of community IRP & Separation Power (first reading) Overview of discussion items. On community IRP Thresholds Board input: Board is concerned that there should be protections built in against ganging up and recommends higher thresholds. Feedback: - Some comments required approval of PDP should not be subject of IRP unless the initiating party of PDP is part of the process. We could leave threshold at 3 SO/ACs and still address Board concern. - If appropriate carve-out, this could be acceptable subject to review of text. - Carve-out is a sensible approach. ACTION ITEM/Conclusion: Becky and David to work on language for carve-out that will be put for discussion on list. On Expert Panels Do we want IRP to resolve inconsistent outcomes? Decision-making bodies need to contemplate how to resolve issues and effects on community. It should be something that should be addressed in PDP and limited to addressing failures of Expert Panels outside of in conflict with Mission. Board input: IRP should be used for violations of Bylaws or Articles. We do not want people making decisions over opinion of panel. There are procedures to follow. Feedback: - Concern that practical solution to inconsistent panel decisions. On separation process Feedback: / Conclusion: We will be moving forward with first reading. Language on carve-out will be sent to the list. Rec 5 - Mission On Numbers ICANN Board has proposed alternative formulation for numbers. It has added substantive role of ratifying policy at global level that are reasonably related to IP and AS numbers. It creates a role that cannot be changed. MOU with RIRs provide alternate mechanism for changing this. We get into a disconnect between MOU and Bylaws. Feedback: Online discussions with Bruce. We still feel it is important to keep this reference to ASO MOU given that we are clearly defining ICANN's role based on an agreement between ICANN and RIRs. Board is okay with this. If no further concerns from Board, our strong preference is to keep Third Proposal language. Board input: Alternative may be paragraph in ASO MoU. ACTION ITEM/Conclusion: Board to reach out to ASO and come up with proposal. On Root Servers RSSAC has proposed that ICANN's role is to facilitate coordination of the operation. ICANN Board language indicates an operational role and considers inputs from the communities dependent on the root server system. Board input: Would support text from RSSAC but need to discuss first. ACTION ITEM/Conclusion: Board to reach out to RSSAC and come up with proposal. On Consumer Trust Robust discussions on list with respect to language. AOC creates an obligation in context of new gTLDs expansion. It is being carried over in review section of Bylaws. Significant concerns voiced on scope of ICANN's role. Suggestion that we put general consumer trust issue in Work Stream 2 for further discussion. Feedback: - Disagree with pushing it to WS2. Part of getting AOC in Work Stream 1 is dealing with that issue. It might be helpful to go back to original source to see if we may have any assistance on this. - Much of what we have in AoC is already in Bylaws. This, however, was not. It is important to look at the AoC paragraph. Item on Consumer Trust is a chapeau leading into the reviews. It is something that is generally applicable, not just new gTLDs. It is within mission of contractual compliance. - We are trying to discuss a broader issue than what was originally in the AOC. AOC review section is within our report. What is meant by market place, consumer trust etc is beyond AOC and should be discussed in WS2. - Paragraph 3 is an introductory text. a - b - c -d link to specific commitments in 7 - 8 - 9. It specifically relates to expansion of TLD space and calls for specific review with respect to that. Comment that 3 is only about gTLDs is incorrect. We have transposed the commitment that is referenced in 3 c and articulated in 9. - Agree with pushing to WS2. - Commitment to consumer trust in DNS market place means in gTLD space. Against pushing to WS2. - Paragraph 3 of AOC is a chapeau to reviews. Inappropriate to read it as brand new. - AOC points is for WS1. We are trying to go beyond what is in AOC and there is a lot of concern about applicability. It would be a game change if add components to WS1. This needs more work. - Language cannot be in use. We cannot proceed with expansive interpretation - It is obvious that goes beyond gTLDs but ok to go back to first references. ACTION item/Conclusion: Get input from NTIA on whether it was meant to be a chapeau and share on list. Conclusion: Incorporate the AoC as it stands as part of WS1 but continue to review the issue of extending Consumer Trust as part of WS2 AOB /