A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | AA | ||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Area | Summary | Degree of support | Response of sub-team | ||||||||||||||||||||||||
2 | 1 | John Poole | Other | SUMMARY - I submit that ICANN (including its “ICANN community”) is failing in its obligations noted by the DOJ Antitrust Division above, and further, that the “ICANN community” is neither representative of, nor accountable to, most domain name registrants who comprise a core constituency of the global internet community as “consumers” of domain names. The “ICANN community” structure is not balanced, and fails to reflect a fair, proportionate, and accountable representation of the full global internet community. The “ICANN community” structure needs to be reformed or replaced in order that there may be an accountable and properly balanced representation of the full global internet community, including all registrants, and other constituencies presently excluded or marginalized. | General complaint that ICANN does not represent the interests of Registrants - quotes ALAC evaluation report. | It is not within the remit of this group to evaluate or propose changes to the overall structure of SO and AC groups established by ICANN's Bylaws. | ||||||||||||||||||||||
3 | 2 | GNSO-ISPCP | Track 1 | With respect to Track 1 “Review and develop recommendations to improve SO and AC processes for accountability, transparency, and participation that are helpful to prevent capture” we have reservations only to “Rec. 4 under Transparency”: Meetings and calls of SO/ACs and Groups should normally be open to public observation. When a meeting is determined to be members-only, that should be explained publicly, giving specific reasons for holding a closed meeting. We are in full agreement to this recommendation on SO/AC level. On SG/C level we recommend this being applied just in case of F2F meetings. SG/C calls should usually deemed as members-only since at almost every call sensitive commercial or private information is been shared. Each call could be determined by the chair in advance as being open. | Qualified Support - Reservation Recommendation 4. | Updated meeting records publication practice to resolve this concern. | ||||||||||||||||||||||
4 | 3 | SSAC | Track 1 | The SSAC notes the Summary of Best Practice Recommendations for Accountability, Transparency, and Participation within SO/AC/Groups and agrees that it would be beneficial to determine and implement those best practices which are applicable to SSAC’s structure and purpose. | Qualified Support | Clarified that implementation of Good Practices are optional, on p. 8: "AC/SO/Groups are only expected to implement good practices to the extent that these practices are applicable and an improvement over present practices, in the view of AC/SO/Group participants." | ||||||||||||||||||||||
5 | 4 | GNSO-BC | Track 1 - Accountability | The BC endorses the view that "each AC and SO is accountable to the segment of the global community that each SO/AC was designated to represent in the ICANN Bylaws.” | Support that SOACs represent their communities. | Acknowledge support | ||||||||||||||||||||||
6 | 5 | ICANN Board | Track 1 - Accountability | #ERROR! | Qualified Support | Add a Good Practice in Accountability: Each Decisional Participant should publish its decision when notifiying the Empowered Community (EC). Publication should include description of processes followed to reach the decision. This would create an opportunity for aggrieved parties to complain to the ICANN Ombuds if an AC/SO failed to follow its required processes to reach that decision. Nothing more is required to ensure that each AC/SO in the EC is properly representing the views of its represented community. Regarding links to AC/SO/Group documents, we support the Board's recommendation. We note that ICANN staff would have the responsibility to maintain those links on the ICANN website, under the heading "Accountability" | ||||||||||||||||||||||
7 | 6 | ICANN Board | Track 1 - Accountability | Beyond the new Empowered Community powers and rights laid out in the Bylaws, there are also additional areas where the SOs and ACs collectively have more responsibility for helping ICANN meet its Bylaws’ obligations. For example, while ICANN is responsible for making sure that the Specific Reviews are conducted in accordance with Section 4.6 of the ICANN Bylaws, the community plays an important role in making sure that the Reviews happen in a timely manner. The SOs and ACs are responsible for selecting the Review Teams, for performing the reviews and delivering reports. Based on the Bylaws, there is fixed time between each review cycle, so the longer the process takes, the shorter the period of time for implementation before the next review cycle hits, which evaluates the outcomes of the implementation of the reviews. Are there things that the SOs and ACs could do collectively to further this work in a timely basis? | Qualified Support | We are unable to identify any mechanism whereby AC/SO can inidvidually or collectively make their work more timely, in the selection of team members. performing their work, and delivering a report. RInalia: define review scope ahead of time, and do collective determination of RT members. Steve noted that bylaws determine scope of Reviews; and bylaws require chairs of AC/SOs to select review team members from candidates offered by AC/SOs. Rinalia: AC/SO chairs could come together to resolve problems/questions occuring during a review. | ||||||||||||||||||||||
8 | 7 | RySG | Track 1 - Accountability | The RySG supports the consensus view that ICANN SOs and ACs are accountable to the segment of the global Internet community that each SO/AC was designed to represent in the ICANN Bylaws and acknowledges that the proposed best practice recommendations could contribute to an increased accountability, transparency, and participation within SOs and ACs. The RySG further agrees with the CCWG-Accountability that the proposed best practices should not become part of the ICANN Bylaws, or that SOs/ACs should be required to implement them. | Supports | Clarified that implementation of Good Practices are optional, on p. 8: "AC/SO/Groups are only expected to implement good practices to the extent that these practices are applicable and an improvement over present practices, in the view of AC/SO/Group participants." | ||||||||||||||||||||||
9 | 8 | GNSO-BC | Track 1 - Best Practices | The BC supports the Track 1 recommendaions for best pratices, and would consider implementaion in the BC "to the extent these practices are applicable and an improvement over present practices.” | Qualified Support | Acknowledge support | ||||||||||||||||||||||
10 | 9 | GNSO-NCSG | Track 1 - Best Practices | NCSG supports the 25 “best practices” recommendations that each SO/AC/Group is encouraged to implement. We also support the recommendation that future Accountability and Transparency Review Teams (ATRT) examine implementation of these best practices among SO/AC/Groups. | Supports Recommendation | Acknowledge support | ||||||||||||||||||||||
11 | 10 | INTA | Track 1 - Best Practices | INTA supports creating a list of “best practices” for SO/AC accountability, transparency, participation, outreach, policy and procedure and having future Accountability and Transparency Review Teams (ATRTs) examine the extent to which SOs/ACs have implemented them. It is INTA’s view that these “best practices” need not be mandatory and should not be made part of ICANN’s bylaws at this time. | Support for Recommendation | Clarified that implementation of Good Practices are optional, on p. 8: "AC/SO/Groups are only expected to implement good practices to the extent that these practices are applicable and an improvement over present practices, in the view of AC/SO/Group participants." | ||||||||||||||||||||||
12 | 11 | ALAC | Track 1 - Best Practices - ATRT | The ALAC does not support the explicit incorporation of AC/SO best practices reviews into the ATRT scope. The periodic organizational reviews are a more appropriate opportunity to do such reviews. If a future ATRT chooses to do such a review, it is already wholly within its scope and prerogative. | Does not support ACSO BP being in ATRT. | Revised recommendation to say that ICANN's Organizational Reviews should assess implementation of Good Practices | ||||||||||||||||||||||
13 | 12 | GNSO-NCSG | Track 1 - Best Practices - ATRT | NCSG supports the 25 “best practices” recommendations that each SO/AC/Group is encouraged to implement. We also support the recommendation that future Accountability and Transparency Review Teams (ATRT) examine implementation of these best practices among SO/AC/Groups. The NCSG recommends a change to the ICANN Bylaws at Sec 4.6 b, and adding to documented procedures for Accountability and Transparency reviews. For example, the following could be added to the Bylaws: §4.6(ii): (G) assessing and improving accountability procedures of the Supporting Organisations and Advisory Committees. The specifics, such as the recommendations in the report, could be left to lesser mechanisms. | Supports Recommendation on inclusion in ATRT + Suggestion | Revised recommendation to say that ICANN's Organizational Reviews should assess implementation of Good Practices | ||||||||||||||||||||||
14 | 13 | ICANN Board | Track 1 - Best Practices - ATRT | On the recommendation that future Accountability and Transparency Review Teams (ATRTs) be encouraged to examine implementation of these best practices among SO/AC/Groups, the Board is concerned this would significantly expand the scope and efforts of the ATRT review team, as well as the organizational staff supporting them. The scope of the ATRT review as it stands is already quite extensive. The proposed additional scope that would include review of actions across all SO/ACs and subgroupings thereof, while important and relevant, may not be scalable in terms of resources. We encourage the CCWG-Accountability to consider whether this recommendation may be better addressed as part of the organizational reviews conducted by independent examiners for each group. The ATRT review process can take into consideration the reports of the independent examiners as part of their overall work without delving into the remit of the organizational reviews. If there are cross-community accountability efforts identified by the group, then the propriety of the inclusion of any of those efforts in an ATRT review scope should be considered at that time. | Concerns given current scope of ATRT reviews which is already quite extensive. | Revised recommendation to say that ICANN's Organizational Reviews should assess implementation of Good Practices. Clarified that implementation of Good Practices are optional, on p. 8: "AC/SO/Groups are only expected to implement good practices to the extent that these practices are applicable and an improvement over present practices, in the view of AC/SO/Group participants." | ||||||||||||||||||||||
15 | 14 | INTA | Track 1 - Best Practices - ATRT | INTA supports creating a list of “best practices” for SO/AC accountability, transparency, participation, outreach, policy and procedure and having future Accountability and Transparency Review Teams (ATRTs) examine the extent to which SOs/ACs have implemented them. It is INTA’s view that these “best practices” need not be mandatory and should not be made part of ICANN’s bylaws at this time. | Support for Recommendation | Clarified that implementation of Good Practices are optional, on p. 8: "AC/SO/Groups are only expected to implement good practices to the extent that these practices are applicable and an improvement over present practices, in the view of AC/SO/Group participants." | ||||||||||||||||||||||
16 | 15 | SSAC | Track 1 - Best Practices - ATRT | However, the SSAC does not believe it is appropriate to incorporate into the scope of future Accountability and Transparency Reviews (ATRTs) a review of the extent to which SO/AC/Groups have implemented best practices in the areas of accountability, transparency, participation, and outreach. The scope of ATRTs is already extensive and it would be more appropriate to incorporate such a review into the 5-yearly independent organizational reviews required by ICANN bylaws Section 4.4.4 Such inclusion does not warrant a change to ICANN's bylaws and could simply be added by ICANN staff to documented procedures for accountability and transparency reviews. | Does not support ACSO BP being in ATRT. | Revised recommendation to say that ICANN's Organizational Reviews should assess implementation of Good Practices | ||||||||||||||||||||||
17 | 16 | GNSO-NCSG | Track 1 - Best Practices - Capture | Despite the 25 recommendations, there remains a broader question that does not seem fully answered. One of the fundamental motivations for this WS2 effort was to address the notion of “capture,” an issue raised by the NTIA regarding internal capture by a subset of SO/AC members, and concern that incumbent members might exclude new entrants to an SO/AC. Do the recommendations in Track 1 fully address this fundamental question? The recommendations appear to partially address the issue of excluding new members through recommending an appeal process, etc., but internal capture appears less well dealt with. For example, issues such as term limits, balance of new and longer serving members on committees, diversity in committees and working groups, length of time before returning to committee positions, among others, do not appear to feature in the recommendations. While recognizing that there is often a small pool to draw on for leadership positions, particularly among volunteer communities, concerns have been expressed that leadership structures in the community often comprise the same individuals rotating among the same roles, which can be considered a form of capture. Ensuring that committees and other community structures with executive powers are able to resist and address internal capture through term limits and diversity, among others, is critical to good governance. It would be useful to understand how the recommendations concretely address the issue of capture in more detail rather than the comment in the draft that the recommendations are “helpful to prevent capture.” | concerns - It would be useful to understand how the recommendations concretely address the issue of capture in more detail rather than the comment in the draft that the recommendations are “helpful to prevent capture.” | A minority of work team members want to add a good practice to consider term limits, for AC/SO/Groups that choose to hold elections. We do not support imposition of country and population-based representation in AC/SO/Groups. Some AC/SO achieve geographical "diversity by design" by having representatives from each region. While we will not recommend gender quotas, we ask if the WS2 group looking at Diversity has any recommendations that could become good practices. We believe that good practice recommendations, taken together, can reduce the potential for a subset of AC/SO/Group members to capture decision-making and officer posts. Moreover, good practices on participation should reduce the potential for a subset of members to exclude interested new members who are otherwise eligible. | ||||||||||||||||||||||
18 | 17 | ALAC | Track 1 - Best Practices - Reporting | The "best practices", one by one, each make sense. However, together the ALAC has concerns about the impact on groups remembering that these are all volunteers with often relatively minimal staff support. Accountability is important, but a fully accountable group that does or nothing other than be accountable has no value within ICANN. | Supports but some concerns. | Clarified that implementation of Good Practices are optional, on p. 8: "AC/SO/Groups are only expected to implement good practices to the extent that these practices are applicable and an improvement over present practices, in the view of AC/SO/Group participants." | ||||||||||||||||||||||
19 | 18 | GNSO-NCSG | Track 1 - Best Practices - Reporting | Further, some of the recommendations burden the volunteers of the SO/ACs with time-consuming administrative tasks. For instance, the suggestion that a report be published annually on how the respective group can “improve accountability, transparency, and participation, describing where they might have fallen short, and any plans for future improvements” would be time consuming for the volunteers to produce and lend itself to bias. Other options might warrant consideration - for example, engaging the services of an external consultant to objectively produce such a report for the entire community. | concerns regarding time of volunteers to create reports on best practices. | We updated the practice to say this is a brief report. Clarified that implementation of Good Practices are optional, on p. 8: "AC/SO/Groups are only expected to implement good practices to the extent that these practices are applicable and an improvement over present practices, in the view of AC/SO/Group participants." | ||||||||||||||||||||||
20 | 19 | TSantosh | Track 1 - Best Practices - Reporting | Furthermore, the draft recommendations must advise SO/ACs to regularly assess, if it is accomplishing its accountability commitments, taking into consideration a range of internal and external stakeholder perspectives. Reviews may include an analysis of strengths and challenges in addition to recommendations for improvement. The annual report that the SO/AC Groups publish (As per recommendation 5 on Pg.18 of Draft Recommendations), must also include these areas for improvement and a strategy that may be adopted to fill these gaps. | Unclear | We updated the practice to say this is a brief report. Clarified that implementation of Good Practices are optional, on p. 8: "AC/SO/Groups are only expected to implement good practices to the extent that these practices are applicable and an improvement over present practices, in the view of AC/SO/Group participants." | ||||||||||||||||||||||
21 | 20 | TSantosh | Track 1 - Best Practices - Reporting | In addition to having a strategy for outreach to different community members, each SO/AC must at the end of the year assess its efficacy in enhancing participation from diverse parts of the community and must publish its findings. | Suggestion - linked to Intra-ICANN-Community diversity. | We updated the practice to say this is a brief report. Clarified that implementation of Good Practices are optional, on p. 8: "AC/SO/Groups are only expected to implement good practices to the extent that these practices are applicable and an improvement over present practices, in the view of AC/SO/Group participants." | ||||||||||||||||||||||
22 | 21 | RySG | Track 1 - Transparency | We note the call for open meetings, public notes, minutes and recordings, and a publicly visible mailing list. There is a public benefit that could follow but there may also be less favorable consequences including diminishing the free-flow of beneficial interchange among registries concerning ICANN policy matters. If this provision is in the final report the RySG will consider whether and to what extent, if any, its adoption would be appropriate. There are already important opportunities that allow for public debate and participation, for example the open RySG sessions during ICANN meetings, our meetings with the Board, cross-constituency/SG sessions, etc. . | Recommendation on open meetings etc could prevent RySG from approving this recommendation. | We updated meeting records publication practice to resolve this concern. | ||||||||||||||||||||||
23 | 22 | RySG | Track 1 - Transparency | The RySG suggests that the CCWG-Accountability reviews transparency recommendation 5 (‘Notes, minutes, or recordings of all membership meetings should be made publicly available.’) and participation recommendation 4 (‘For any meetings, be they closed to members or open to anyone, the members have to be able to access notes, minutes and/or recordings, subject to exceptions for confidential matters.’) as they might be seen as confusing or inconsistent. | Notes a possible inconsistency between recommendation 4 and 5. | We updated meeting records publication practice to resolve this concern. | ||||||||||||||||||||||
24 | 23 | TSantosh | Track 1 - Transparency | In order to effectively thwart a risk of ‘capture’, it is imperative to ensure diversity in SO/AC/Groups. While speaking of diversity, the importance of ‘Geographic Diversity’ cannot be overstated. Therefore, it is strongly recommended that geographies (countries) where the largest number of internet users come from should be provided with voting rights and membership proportionate to the legions of internet users they seek to represent. Furthermore, each SO/AC must ensure equitable representation from each region. | Links this to a deversity requirement advocating to voting rights per country based on population of Internet users. | We do not support imposition of country and population-based representation in AC/SO/Groups. Some AC/SO achieve geographical "diversity by design" by having representatives from each region. | ||||||||||||||||||||||
25 | 24 | TSantosh | Track 1 - Transparency | It appears that fluency in English is a core skill for ICANN leaders. While, no data is available to substantiate this claim, the proportion of leaders fluent in English is estimated to be 90%, an alarmingly high number suggesting that deeper exclusion occurs when a representative is not fluent in English. In order to reach out to maximum number of community members, ‘Main Language’, must also include world’s top ten most widely spoken languages in addition to the official languages. Currently, newsletters and brochures are published only in the six Official UN Languages and this acts as a major barrier to entry for people belonging to popular language groups, that fall outside of this list. | Links to diversity and requesting that ICANN material but published in the world's TOP TEN most spoken languages IN ADDITION to the OFFICIAL languages. | This suggestion would apply to any document published by ICANN--not just SO/AC publications. We recommend that if ICANN were to expand the list of languages that it supports, this support should also be made available to SO/AC/Groups. | ||||||||||||||||||||||
26 | 25 | TSantosh | Track 1 - Transparency | An indicative list of what may qualify as a ‘confidential matter’ may be provided (similar to an exemplary list provided for holding a closed meeting on Pg 6 of the Draft Recommendations). | Suggestion | We amended our report to indicate that the list of exemplary reasons for closing a meeting are also exemplary reasons for declaring that items are 'confidential' | ||||||||||||||||||||||
27 | 26 | ALAC | Track 2 | The ALAC supported the original position of the SOAC-Accountability Working Group to not pursue the accountability roundtable. That was overruled by the CCWG. As currently proposed there is a high likelihood that it will become a meaningless exercise taking up valuable time at ICANN meetings with little benefit. That notwithstanding, if the decision is made that it should be kept needs to be further thought given to exactly what it will do and what its aims are. | Does not believe there should be a MART. | We reverted to original recommendation: not to implement a Mutual Accountability Roundtable | ||||||||||||||||||||||
28 | 27 | GNSO-BC | Track 2 | The BC supports the Track 2 recommendation that an "Accountability Roundtable be an optional addition to the Annual General Meeting, subject to approval of SO/AC chairs.” | Supports Recommendation | Acknowledge support | ||||||||||||||||||||||
29 | 28 | GNSO-ISPCP | Track 2 | Regarding Track 2 “Mutual Accountability Roundtable” we agree in principle to the WG recommendation to leave the decision of holding such a roundtable at the AGM to the SO/AC chairs. In addition, we suggest to investigate this question in more detail when it once comes to a more holistic review of the organisation. | Qualified Support | Acknowledge support | ||||||||||||||||||||||
30 | 29 | GNSO-NCSG | Track 2 | NCSG supports the finding that the “Mutual Accountability Roundtable” be an optional accountability measure subject to the approval of the SO/AC Chairs. | Supports Recommendation | Acknowledge support | ||||||||||||||||||||||
31 | 30 | ICANN Board | Track 2 | We note that this topic raises the same question as the one addressed in Track 1 on “who watches the watchers” or “in what ways should the respective groups within the community be accountable to the community?” We believe that any cross-constituency accountability mechanism should be informal in nature, but codified and communicated in some way so as to make it broadly known and adopted as a community-wide norm. Considerations of mutual accountability could also be broader than how parts of the community can talk to each other and share best practices. The stronger the requirements and considerations of collective accountability are, the less likely the community is to need to build structures such as a mutual accountability roundtable. We encourage the community (within respective SOs and ACs, and as a collective) to explore this aspect further, as appropriate, and to consider, in relation to each group’s participation in the ICANN community, what the collective social contract might be regarding accountability to the overall community. | concerns vs formalims | While the Board says that mechanisms for mutual accountability should be informal, it wants the requirements and considerations of 'collective accountability' to be stronger. We do not believe it possible to have an 'informal' practice that is also 'codified' and 'community-wide'. As noted in our report, we believe that each SO/AC/Group is accountable to the stakeholders it was created to represent. (i.e., Vertical Accountability"). We note that the Ombuds Office responds to grievances regarding whether an AC/SO/Group properly followed its vertical accountability procedures. Transparency about EC decisions could reveal whether an AC/SO/Group considered interests of the broader community. But it unrealistic to expect an AC/SO/Group to explcitly attend to interests of all other AC/SO/Groups. No changes recommended in response to this comment, unless the Board proposes an objective standard for 'collective accountability' that is acceptable to CCWG. | ||||||||||||||||||||||
32 | 31 | INTA | Track 2 | INTA supports the idea of holding a “Mutual Accountability Roundtable,” comprising the ICANN Board, CEO and SO/AC chairs to discuss key issues of concern and how their constituencies address the issues. We support having ICANN staff coordinate a roundtable at each ICANN Annual General Meeting if a majority of the SO/AC chairs agree to meet. It is INTA’s view that the Mutual Accountability Roundtable need not be made mandatory at this time. | Qualified Support - does not believe it should be mandatory | A Mutual Accountability Roundtable was not supported by CCWG at the ICANN59 meeting. We reverted to original recommendation: not to implement a Mutual Accountability Roundtable | ||||||||||||||||||||||
33 | 32 | RySG | Track 2 | The RySG supports the report’s conclusions on Track 2 (the “Mutual Accountable Roundtable” should be optional, subject to approval of SO/AC chairs) and Track 3 (the IRP should not be made applicable to SO/AC activities). | Supports Recommendation | Acknowledge support | ||||||||||||||||||||||
34 | 33 | SSAC | Track 2 | The report recognizes that a “Mutual Accountability Roundtable”, one in which SO/ACs are accountable to each other, is inappropriate. It nevertheless proposes a very formal approach to an “Accountability Roundtable” involving a 90 minute Public Session at an ICANN AGM Meeting, open to all SO/AC/Group chairs, and joined by the ICANN CEO and Board Chair, subject to the agreement of a majority of SO/AC chairs. The SSAC considers that a more informal approach should be adopted, which involves the exchange of views, experiences and best practices during the course of regularly scheduled meetings between SO/AC chairs only. | Does not support the recommendation for the MART as proposed being overly formal. | We reverted to original recommendation: not to implement a Mutual Accountability Roundtable | ||||||||||||||||||||||
35 | 34 | GNSO-BC | Track 3 | The BC supports Track 3 recommendation that the IRP (Independent Review Process) "should not be made applicable to SO/AC activities, because it is complex and expensive, and there are easier alternatives to challenge an AC or SO action or inaction.” | Supports Recommendation | Acknowledge support | ||||||||||||||||||||||
36 | 35 | GNSO-ISPCP | Track 3 | With respect to Track 3 “Assess whether the Independent Review Process (IRP) should be applied to SO/AC activities“ we fully support the CCWG recommendation that “the IRP should not be made applicable to SO/AC activities, because it is complex and expensive, and there are easier alternative ways to challenge an AC or SO action or inaction”. | Supports Recommendation | Acknowledge support | ||||||||||||||||||||||
37 | 36 | GNSO-NCSG | Track 3 | NCSG supports the finding that the “IRP should not be made applicable to activities of SO/AC/Groups.” | Supports Recommendation | Acknowledge support | ||||||||||||||||||||||
38 | 37 | ICANN Board | Track 3 | As the CCWG-Accountability notes: The IRP requirements and rules are not developed to attach to acts of the SOs/ACs or the Empowered Community; and adjusting the rules currently framed in terms of whether the ICANN Staff or Board violated the Bylaws would represent a significant change to the IRP – as well as consideration of, for example, the scope of standing panel expertise, and size. While the IRP is probably not the appropriate place to take grievances against SOs/ACs/Empowered Community, we note that the recommendations do not offer alternative mechanisms for what should happen if failure in accountability occurs. It would be beneficial for ICANN and the community if the CCWG-Accountability were to consider and identify what alternate mechanism, existing or new, should apply to address grievances against SOs/ACs/Empowered Community. | Qualified Support - If the IRP is not appropriate the community needs to decide how to deal with this | We cite the ombuds WS2 group which argues that The Ombuds handles these conflicts. ICANN SO/ACs may already take their grievances to the Ombuds Office. The board suggests that actions of the Empowered Community (EC) should be subject to challenges and grievance procedures. The EC is merely the aggregation of decisions reached by participating AC/SOs. However, review by the Ombuds (ICANN Bylaws Article 5) would be appropriate in response to a complaint about whether an AC/SO properly reported its decision to the EC, and whether actions of EC Decisional Participants are reported accurately in accord with ICANN bylaws. | ||||||||||||||||||||||
39 | 38 | INTA | Track 3 | INTA does not agree with the Draft Report’s conclusion that the Independent Review Process (IRP) should not be applied to SO/AC activities. The working group has adopted this position based on the rationale that the IRP process is complex and expensive. They note that there are easier alternative ways to challenge an AC or SO action or inaction such as engagement with the Ombudsman. INTA respectfully disagrees with this conclusion. There may be some circumstances where it may be appropriate to apply the IRP to SO/AC accountability actions or inactions. This is based on the concern that the Ombudsman may not be an effective mechanism to hold SO/ACs to account, as the Ombudsman is employed by ICANN and therefore, could be subject to influence by ICANN staff and the ICANN Board. Independent review should be available to aggrieved parties who could then determine whether the alleged grievance and possible remedies merit the investment of resources demanded by an IRP. | Does not agree IRP should not apply to SOACs - argues there could be some circumstances. | This view was expressed by only one commenter, and was not supported by CCWG at the ICANN59 meeting. Therefore we are holding to the consensus view, that the IRP should not apply to SO/AC activities. | ||||||||||||||||||||||
40 | 39 | RySG | Track 3 | The RySG supports the report’s conclusions on Track 2 (the “Mutual Accountable Roundtable” should be optional, subject to approval of SO/AC chairs) and Track 3 (the IRP should not be made applicable to SO/AC activities). | Supports Recommendation | Acknowledge support | ||||||||||||||||||||||
41 | 40 | SSAC | Track 3 | The SSAC agrees that the IRP should not be made applicable to activities of SO/AC/Groups. | Supports Recommendation | Acknowledge support | ||||||||||||||||||||||
42 | 41 | TSantosh | Track 3 | While, the Independent Review Process (IRP) cannot be made applicable to disputes brought against or involving SO/ACs, it is advisable to have more clarity on procedures to challenge an AC or SO action or inaction. The draft recommendations should look into the feasibility of having an independent party dedicated to addressing such grievances. Even though, it suggests an Ombudsman complaint as a method to address grievances, it may not be the most expeditious process, since an Ombudsman cannot devote their entire time to this process. Therefore, a mechanism to hold SO/ACs to account other than the Ombudsman is needed. | Qualified Support - If the IRP is not appropriate the community needs to decide how to deal with this. | We now cite the Ombudsman and WS2 group examining the Ombuds Office, who believe the Ombuds is able to handle these complaints, per ICANN Bylaws Article 5. | ||||||||||||||||||||||
43 | ||||||||||||||||||||||||||||
44 | ||||||||||||||||||||||||||||
45 | ||||||||||||||||||||||||||||
46 | ||||||||||||||||||||||||||||
47 | ||||||||||||||||||||||||||||
48 | ||||||||||||||||||||||||||||
49 | ||||||||||||||||||||||||||||
50 | ||||||||||||||||||||||||||||
51 | ||||||||||||||||||||||||||||
52 | ||||||||||||||||||||||||||||
53 | ||||||||||||||||||||||||||||
54 | ||||||||||||||||||||||||||||
55 | ||||||||||||||||||||||||||||
56 | ||||||||||||||||||||||||||||
57 | ||||||||||||||||||||||||||||
58 | ||||||||||||||||||||||||||||
59 | ||||||||||||||||||||||||||||
60 | ||||||||||||||||||||||||||||
61 | ||||||||||||||||||||||||||||
62 | ||||||||||||||||||||||||||||
63 | ||||||||||||||||||||||||||||
64 | ||||||||||||||||||||||||||||
65 | ||||||||||||||||||||||||||||
66 | ||||||||||||||||||||||||||||
67 | ||||||||||||||||||||||||||||
68 | ||||||||||||||||||||||||||||
69 | ||||||||||||||||||||||||||||
70 | ||||||||||||||||||||||||||||
71 | ||||||||||||||||||||||||||||
72 | ||||||||||||||||||||||||||||
73 | ||||||||||||||||||||||||||||
74 | ||||||||||||||||||||||||||||
75 | ||||||||||||||||||||||||||||
76 | ||||||||||||||||||||||||||||
77 | ||||||||||||||||||||||||||||
78 | ||||||||||||||||||||||||||||
79 | ||||||||||||||||||||||||||||
80 | ||||||||||||||||||||||||||||
81 | ||||||||||||||||||||||||||||
82 | ||||||||||||||||||||||||||||
83 | ||||||||||||||||||||||||||||
84 | ||||||||||||||||||||||||||||
85 | ||||||||||||||||||||||||||||
86 | ||||||||||||||||||||||||||||
87 | ||||||||||||||||||||||||||||
88 | ||||||||||||||||||||||||||||
89 | ||||||||||||||||||||||||||||
90 | ||||||||||||||||||||||||||||
91 | ||||||||||||||||||||||||||||
92 | ||||||||||||||||||||||||||||
93 | ||||||||||||||||||||||||||||
94 | ||||||||||||||||||||||||||||
95 | ||||||||||||||||||||||||||||
96 | ||||||||||||||||||||||||||||
97 | ||||||||||||||||||||||||||||
98 | ||||||||||||||||||||||||||||
99 | ||||||||||||||||||||||||||||
100 |