Board Input into the IANA Stewardship Transition / Enhancing ICANN Accountability Processes
Board provides clarification on Recommendation 2 compromise
24 February 2016
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2016-February/011420.html
Hello All,
In response to the question from Brett Schaefer:
>> I would hope that we could get explicit clarification and commitment from the Board that, if the GAC cannot decide or chooses not to become a decisional participant, that the Board would support lowering the thresholds for exercising all EC powers to avoid the requirement for SOAC unanimous support to exercise those powers.
The Board supports the language in the report, at Page 72 of Annex 2:
"The thresholds presented in this document were determined based on this assessment. If fewer than five of ICANN's SOs and ACs agree to be Decisional Participants, these thresholds for consensus support may be adjusted. Thresholds would also have to be adjusted if ICANN changes to have more SOs or ACs."
The Board's earlier comment on this issue from Page 5 of our 14 December 2015 Comments to the Third Draft Proposal from the CCWG is as follows:
"B. Board Comments and Supporting Rationale on Further Defining Thresholds
The thresholds as set out in the Proposal (Pages 22-23) seem well defined for the design of ICANN today. The Board would not support lowering of any of these thresholds because these community powers represent the voice of the ICANN community. A reduction of the threshold could risk that a decision does not reflect the community's will.
While the thresholds seem well defined for the design of ICANN today, the Board recommends further defining the thresholds for exercising community powers in the event that the number of SOs or ACs change. Leaving this issue for future consideration raises the potential for renegotiation of the community thresholds. This potential for renegotiation adds a level of instability and a lack of predictability. As a result, the Board recommends (1) clarifying that the thresholds identified in the Proposal are based on the current structure; and (2) identifying the percentages that will be applied in the event that there is a change in the number of SOs or ACs in the future."
When we previously discussed this with the CCWG, we understood from Page 72 of Annex 2 that the CCWG does not want to set percentages and has agreed to revisit the thresholds if the number of participants change.
We will further discuss this issue when it becomes clear who the future participants will be, and whether fewer than five of ICANN's SOs and ACs agree to be Decisional Participants in the Empowered Community.
Regards,
Bruce Tonkin
Board position on the GAC carve out
19 February 2016
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2016-February/011056.html
CCWG Colleagues,
The Board has a serious and continued concern about the issues being raised that may result in the reduction of the GAC's ability to participate in community decision making. This is most noticeable in the question of thresholds for board removal, however this is not an issue about removal or even thresholds, it is one part of the community being (or perceiving that it is being) sidelined. The Board's concerns with this issue are not about Board removal, but about maintaining the balanced multistakeholder model.
The Board is against any changes to the long established equilibrium and fairness among the different stakeholders within ICANN. The Board has long supported a threshold of four participants for Board removal in the ultimate escalation method proposed by the CCWG. Selecting one portion of the ICANN community and removing them from the equation - just through the ability to say that the community is unhappy with the acceptance of GAC advice that is within ICANN's bylaws - raises significant concerns about how the multistakeholder model, and the ultimate stability of ICANN as an organization, can be maintained. This carved out exception undercuts the established role of governments within the multi stakeholder process, and could introduce new issues with the acceptance of ICANN's model undermining the work of the CCWG.
We understand that there are concerns with this path from within other parts of ICANN community, including members of the GAC and ALAC. The best course, in our opinion, would be a careful and objective discussion of the whole matter of how advice from ALL parties is appropriately considered within ICANN. If there is a graceful way to remove this matter from the immediate pressure of the deadline of submitting this proposal and make it a priority matter for either the implementation phase or Work Stream 2, we think there will be a solution which is genuinely good for everyone.
We encourage you to share the CCWG's proposal with the Chartering Organizations while the dialog on this outstanding point continues.
Thank you,
Steve Crocker
Chair, ICANN Board of Directors
Board comments on Board removal in the context of GAC advice
17 February 2016
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2016-February/010967.html
Hello All,
To reiterate the Board's position in the case of the carve out compromise involving GAC advice, the Board can agree to reducing the threshold for Board removal to three SOs or ACs, with no more than one objecting, when there was an IRP finding against the Board regarding the acceptance of GAC advice.
For all other attempts to remove the full ICANN Board, the Board does not support lowering the threshold below four SOs or ACs, with no more than one objecting. The power to spill the Board would remain available as contemplated within the CCWG's third draft proposal.
For the avoidance of doubt, if the Board accepts GAC advice within the limitations of ICANN's mission and bylaws, an IRP panel confirms that is the case, and the community simply dislikes the GAC advice - then the threshold of 4 SOs and ACs continues to apply. If the GAC is excluded from participating then this would mean that the ccNSO, GNSO, ASO and ALAC would need to agree that the Board should be removed.
Our view is that past cases relating to disagreement on GAC advice have been focussed on concerns that ICANN is exceeding its mission or is not following its processes. The IRP is the most appropriate vehicle to resolve disputes in this area. In general the Board consults widely with the whole community before accepting the advice from any one part of the community. We think a situation where the community broadly disagrees with an action the Board has taken that is within the mission and bylaws is likely to be extremely rare, and the threshold of 4 SOs and ACs is still appropriate in that scenario if the community simply dislikes the Board's decision.
Regards,
Bruce Tonkin
Board position on indemnification text
12 February 2016
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2016-February/010886.html
Hello All,
The Board does not have any objection to the inclusion of text on the advancement of expenses in the indemnification section.
Regards,
Bruce Tonkin
ICANN Board Liaison to the CCWG
Board suggested text relating to ICANN's role with respect to Root Servers
9 February 2016
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2016-February/010847.html
Hello All,
Below is some revised text regarding ICANN scope of responsibilities related to root servers.
The text is not separated into two separate points. One relates to coordination role and the other relates to the operational role.
ICANN:
1) "Facilitates coordination of the operation and evolution of the DNS root name server system."
2) "In its role, ICANN also participates in the operation of DNS root name server system in keeping with ICANN’s security and stability remit."
Regards,
Bruce Tonkin
Board Comments on Recommendation #9 — AOC Reviews
4 February 2016
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2016-February/010588.html
Recommendation 9 – AoC Reviews
Following on from the recent email exchange to clarify the Board's concerns on Recommendation 9, the Board notes that many of its concerns can be addressed during implementation and the development of Operational Standards. The Board has a particular concern with two paragraphs in the most recent version.
At paragraph 54, the Board does not support the language that states "Review Teams are established to include both a limited number of members and an open number of participants." The Board would support this language if it read "Review Teams are established to include both a limited number of members and an open number of observers." The Board does not agree with a Bylaws-mandated inclusion of "participants" in these Review Teams. The Review Team composition is defined and limited because of the specificity of the review. Requiring open participation is not consistent with this purpose.
Similarly, the statement at Paragraph 57 that the Review Team would first try to find consensus among "participants", and only if that is not successful, seek consensus among members. Consensus polling should only be among the Review Team members. The Board does not support maintaining "if consensus cannot be reached among the participants" at the beginning of that paragraph.
Regards,
ICANN Board Liaison to the CCWG
Board Comments on Recommendation #5 — Mission Statement
4 February 2016
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2016-February/010587.html
Hello All,
Recommendation 5 - Mission Statement
On the mission statement, the Board supports the core principles that:
- ICANN shall not impose regulations on services that use the Internet's unique identifiers, or the content that such services carry or provide.
- ICANN shall have the ability to negotiate, enter into and enforce agreements with contracted parties in service of its Mission, including PIC Specifications.
The drafting of the bylaws related to these principles will need to take into account the comments that the Board has previously expressed around use of terms such as "regulations", when ICANN is not a regulator, and the exact definitions of terms such as "services", so as not to exclude services such as domain name registration and domain name registry services. It is inappropriate to include within ICANN's mission a prohibition on regulation, when ICANN is not a regulator.
We remain concerned about the grandfathering discussion and the potential limitations to ICANN's contracting and enforcement abilities.
Rationale on Grandfathering:
The Board's concerns with the recommendation to include "grandfathering" language within ICANN's Mission remain. These concerns exist notwithstanding the words used to describe the concept of "grandfathering". First, as the CCWG-Accountability has continually affirmed, the CCWG-Accountability recommendations are not intended to change ICANN's mission. To this end, any suggestion that ICANN's contracting ability with registries and registrars will be changed as a result of the CCWG-Accountability's work is inconsistent and troublesome. The Board does not agree with the inference, and it does not benefit ICANN or the ICANN community to suggest, that ICANN has previously entered into contracts that go beyond its mission. This introduces uncertainty and instability into ICANN's work.
Second, grandfathering - no matter when the CCWG-Accountability wishes to impose a cut off - could result in inconsistent contracting among different parties and raises the question of unequal treatment among contracted parties.
Finally, the uncertainty around the concept of grandfathering, and the level of detail needed to try to address that uncertainty, has carried the CCWG-Accountability beyond the clarification of ICANN's mission that was anticipated as part of this WS1 transition work. This level of detail is beyond the scope of ICANN's readiness for the transition, and creates opportunities for vagueness and challenge that could be introduced into ICANN's contracts.
The Board understands that one of the concerns driving this discussion is a confirmation that the PICs would remain enforceable. As a result, the Board proposes that a reference to the viability of the PICs be added to the proposition "ICANN shall have the ability to negotiate, enter into and enforce agreements with contracted parties in service of its Mission, including PIC Specifications."
Regards,
Bruce Tonkin
ICANN Board Liaison to the CCWG
Board Comments on Recommendation #6 — Human Rights
4 February 2016
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2016-February/010586.html
Hello All,
In the spirit of the compromise throughout the CCWG proceedings, the Board is modifying its position, and is supportive of inserting a commitment to respect human rights into the ICANN Bylaws as follows:
"Within its Core Values, ICANN will commit to respect internationally recognized Human Rights as required by applicable law. This provision does not create any additional obligation for ICANN to respond to or consider any complaint, request, or demand seeking the enforcement of human rights by ICANN. This Bylaw provision will not enter into force until (1) a Framework of Interpretation for Human Rights (FOI-HR) is developed by the CCWG-Accountability (or another Cross Community Working Group chartered for such purpose by one or more Supporting Organizations or Advisory Committees) as a consensus recommendation in Work Stream 2 (including Chartering Organizations' approval) and (2) the FOI-HR is approved by the ICANN Board using the same process and criteria it has committed to use to consider the Work Stream 1 recommendations."
Rationale:
The clause on the timing of the effective date of the Bylaws provision addressed many, though not all, of the Board's timing concerns. There were still significant concerns regarding some of the other detail, including possible interpretations that could impose human rights responsibilities on those with whom ICANN does business, or whether there are things that ICANN should affirmatively be doing today, in addition to compliance with law.
One of the most pressing concerns that remained with the language was on the potential impact on external entities. The Board remained concerned that the CCWG's attempt to exclude reach to "entit[ies] having a relationship with ICANN", could actually be interpreted in a manner that increases - not insulates - the reach of this provision. When ICANN is challenged for conduct alleged to be in violation of applicable laws on human rights, that that challenge could also reach third parties for alleged failures to protect or enforce human rights within applicable law. This could reach entities with or without contracts, and many of which (including ICANN) have no enforcement power when it comes to the law. This is a potential path to placing an affirmative (and out of mission) obligation to police those with whom ICANN has relationships for potential failures to protect or enforce human rights.
This language could leave the door open for those doing business with ICANN to be held to, for example, the applicable laws in the USA or another place where ICANN is found to do business. The applicable law is not defined as it applies to entities with relationships with ICANN, nor is that the type of language normally included in Bylaws.
The Board supports the removal of the language that causes it concern, while allowing the CCWG to move forward with a recommendation to include a commitment in the Bylaws that ICANN treats human rights as a core value that guides the decisions and actions of ICANN:. We hope this compromise can allow this issue to be closed.
Regards,
Bruce Tonkin
ICANN Board Liaison to the CCWG
Board Comments on Recommendation #4 — Board Removal Liability Mitigation
4 February 2016
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2016-February/010584.html
Hello All,
Following the last CCWG call that discussed the topic of indemnification for community members that participate in developing a written rationale for Board removal, the Board has modified its position to support indemnification for public statements made in the initiation of the Community Forum and in the Community Forum process.
The Board previously identified to the CCWG-Accountability that it would not support the requirement that Board members would have to, as a condition of serving on the Board, sign a waiver of rights to file suit against community members for statements made in the Board removal process. However, the Board also indicated its willingness to explore the possibility of indemnifying community members for suits based on participation in the Board removal process.
The Board then agreed that it would support indemnification for statements made in the written rationale supporting Board member removal, so long as those statements were made in good faith and with due diligence as to their veracity. On the CCWG's 26 January 2016 call, we heard the concerns of some on the CCWG that the limitation to written rationale was not far enough, and that to make this a meaningful provision the indemnification had to also cover statements made within the process leading up to the Board removal.
Hearing the CCWG's concern, the Board has modified its position to support indemnification for public statements made in the initiation of the Community Forum and in the Community Forum process, as well as in the written rationale. The Board remains in objection to a waiver. We believe that this compromise provides the community with flexibility for good faith participation in the removal discussions with sufficient protection if their participation was challenged. ICANN staff has provided the CCWG with proposed Bylaws language to give effect to the indemnification. Particularly with the extension of indemnification to a broader set of actions, it is essential that the community be given tools to assess, from the outset, how to demonstrate that contributions are made in good faith. We expect that guidelines for the running of the Board removal processes will be developed as part of the implementation of the CCWG recommendations. ICANN provided the CCWG with some initial ideas on what those guidelines could look like.
Regards,
Bruce Tonkin
ICANN Board Liaison to the CCWG
Board Communication to CCWG-Accountability
4 February 2016
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2016-February/010583.html
Hello All,
The Board met in Singapore yesterday and discussed several of the CCWG recommendations.
Attached is the summary of the outcome of those discussions.
The topics covered include:
- Recommendation 4 - Board Removal Liability Mitigation - extended the indemnification
- Recommendation 6 - The proposed Bylaw on Human rights - agreed to incorporate a human rights bylaw with proposed text
- Recommendation 5 - The Mission Statement - agreed to principles around content regulation and enforcement of agreements
- Recommendation 9 - AoC reviews - recommending separation of review team members that will do the review, and "observers" that should be able to engage with the members and provide inputs to and feedback on the review beyond simply the public comment process
- Recommendation 11 - GAC Advice and the Role of the Board - reiterated some earlier principles regarding how the Board currently treats GAC advice, and support for getting rationales from each of the Advisory committees for their advice
I will also separately send details under the relevant subject headings, to make it easier to digest for those with a particular interest in one of the topics above.
Regards,
Bruce Tonkin
ICANN Board Liaison to the CCWG
Board Comments relating to GAC Advice
4 February 2016
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2016-February/010572.html
Hello All,
The Board met in Singapore yesterday and discussed several of the CCWG recommendations. We will be providing a full set of comments later today.
Given that there is a call starting in about 10 hours I thought it might be helpful to provide the Board's current thinking on the general topic of the Board's treatment of GAC advice. Note the Board has not had a discussion or formed a position about the thresholds of 51%, 60%, 66% etc, which are currently being debated in the CCWG.
Requirement for Formal Decision
The Board understands the concern that the language in the current bylaws relating to the Board making an initial determination that it intends to act inconsistently with GAC advice might be subject to interpretation. As a matter of clarification, the Board recommends that the current practice of the Board, which allows flexibility, be used when revising the language of this section, so that the Board is not subject to a changed process or new affirmative voting requirements.
The current practice was established and developed after the first Accountability and Transparency Review. At that time, the Board and the GAC, through the Board/GAC Recommendations Implementation Working Group (BGRI), developed a process to lead to consultations between the Board and GAC, if ever necessary. This process document is available at (https://gacweb.icann.org/download/attachments/27132063/2013-04-07-Process%20forConsultations%20between%20ICANN%20and%20GAC.doc?version=1&modificationDate=1376102118000&api=v2). The Board is provided flexibility: "In the event that the Board determines, through a preliminary or interim recommendation or decision, to take an action that is not consistent with GAC advice, the ensuing consultations will be considered "Bylaws Consultations". The Board will provide written notice to the GAC (the "Board Notice") stating, in reasonable detail, the GAC advice the Board determines not to follow, and the reasons why such GAC advice may not be followed." The Board recommends that, to the extent the Bylaws language needs to be clarified on this issue, that it is clarified to align with the current practice that has been discussed, agreed to, and is not problematic in regards to accountability.
Similarly, while the Board is required to take GAC advice into account, the Board understands that recommendation is not intended to impose any new requirements for the Board to take decisions on GAC advice. This issue can be addressed in the Bylaws drafting notes by indicating that the Board should not be obligated to act on all GAC advice through a vote.
Considering Rationale
The Board agrees that all Advisory Committees should be required to provide rationale to accompany advice. The Board understands the CCWG recommendation to place an obligation on the Board, when taking a decision on a piece of advice, to consider whether the Board found the rationale sufficient. The Board would always be in a position to indicate if additional information is needed prior to completing consideration of any piece of advice. The Board does not consider this recommendation to impose a requirement that - separate from when the Board is considering advice - that the Board must provide a specific determination for each piece of advice received regarding whether the Board felt the rationale was sufficient. The Board urges the CCWG to clarify this issue for Bylaws drafting.
Uniform Treatment of Advisory Committee Advice
The Board agrees with the CCWG-Accountability's clarification that, if the Board takes action inconsistent with the Bylaws - even if that action is based upon following the advice of an Advisory Committee - the Board can be subject to an IRP. To the extent that the CCWG believes that it is important to specifically identify this in the Bylaws, the text used should apply to all Advisory Committees, and not solely refer to the GAC.
Regards,
Bruce Tonkin
ICANN Board Liaison to the CCWG
Board Response on Recommendation #9 — AOC Reviews
1 February 2016
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2016-February/010331.html
Dear Steve,
Please find below our responses. Apologies for the delay.
Best regards,
Rinalia
On Wed, Jan 27, 2016 at 11:03 PM, Steve DelBianco <sdelbianco at netchoice.org>
wrote:Bruce — thank you for elaborating on the board's general comment about bringing AoC reviews into the bylaws (Rec 9). Your email helped us understand specific areas where you want to leave more decisions to the board and to the AC/SO chairs.
I have offered response in-line with your comments (see red text below), based upon my notes from multiple CCWG discussions of this topic over the last 12 months.
From: <accountability-cross-community-bounces at icann.org> on behalf of Bruce Tonkin <Bruce.Tonkin at melbourneit.com.au>
Date: Tuesday, January 26, 2016 at 3:19 PM
To: CCWG Accountability <accountability-cross-community at icann.org>
Subject: [CCWG-ACCT] ICANN Board comments on recommendation 9Board Comment - Recommendation 9:
As noted in its comments on the third draft proposal, the Board supports the incorporation of the AOC reviews into the Bylaws, while noting the importance of maintaining operational standards for reviews outside of the Bylaws. While the Board agrees that operational standards should be in alignment with the provisions of the Bylaws, the Board views operational standards as a more suitable place to address multiple review-related operational items that do not belong in the Bylaws.
There are a few specific areas that the Board is flagging in relation to the operational standards-
a) The Board is concerned about potential constrains that may limit flexibility and effectiveness in the operational standards and that certain CCWG-Accountability recommendations may not be aligned with best practices or industry standards, including:
o Fixed numbers of total review team members, as well as a fixed allocation among SO/ACs, without consideration of specific issues and required expertise for a given review.Reply: This regards para 54 in Annex 9, repeated here for convenience:
"Review Teams are established to include both a fixed number of members and an open number of participants. Each SO and AC participating in the review may suggest up to seven prospective members for the Review Team. The group of chairs of the participating SOs and ACs will select a group of up to 21 Review Team members, balanced for diversity and skills, allocating at least three members from each participating SO and AC that suggests three or more prospective members. In addition, the ICANN Board may designate one Director as a member of the Review Team."
CCWG proposed that "chairs of participating SOs and ACs will select a group of *up to 21* Review Team members." The phrase is "up to 21", so we are not actually proposing a fixed number of review team members. (We do acknowledge the need to remove "fixed number of members" from the introductory sentence.)
We are proposing a maximum of 21 members, based on community experience with previous reviews and data provided by staff on the number of members proposed by the community. We proposed 21 in order to accommodate each of the 7 AC/SOs having up to 3 members. We anticipate that some ACs and SOs will not offer 3 names, and have given the AC/SO chairs flexibility to give those member slots to an AC/SO that had higher interest and offered more than 3 candidates (per a comment from GNSO CSG).
On number of Review Team Members: We recommend not specifying a fixed number for Review Teams, but suggest providing guidelines in the Operational Standards on the typical size-ranges of effective and manageable Review Teams. We also recommend giving flexibility to the chairs of the participating SO and ACs to determine the size of each Review Team depending on its purpose. It is possible to provide guidance in the Operational Standards not to exceed a certain figure (e.g. 21) for effectiveness.
In terms of number of nominees per SO/AC: there may be valid reasons for an SO/AC to put forth more than 7 nominees. Example: The GNSO recently endorsed 18 nominees for the Review Team on Competition, Consumer Trust and Consumer Choice (CCT), of which six were selected. Having an arbitrary number of nominees affects available choice and may deter efforts by the selectors to maximize the diversity and expertise needed for the review team. Consider the scenario where each SO/AC puts forth at least 3 names. For the Review Teams on CCT and WHOIS, given that they focus predominantly on gTLD issues, the GNSO may need more than 3 spots on each Review Team. Under the CCWG proposal, GNSO participation would be limited and this may affect the effectiveness of the reviews.
o Unlimited number of participants, in addition to the appointed review team members, potentially affecting the team's productivity.
Reply: This regards para 54 in Annex 9, where CCWG proposed an "open number of participants". Levels of community interest and the principle of transparency argue for that meetings, calls, and email lists for cross-community working groups and review teams be open to the community. We note that chair(s) of the Review Team could restrict posting privileges and consensus calls to appointed members of the Review Team, and thereby manage the team's productivity. CCWG proposed this to ensure that Review Teams work in a predictable method that is consistent with cross community working groups in the ICANN context.
The Board agrees with the use of "observers" for Review Teams to manage productivity while maximizing transparency. It is important to note that the number of Review Team members and observers/other participants have cost implications. The number of Review Team members has a direct and significant impact on the cost of travel and meeting facilities. Additionally, the work of managing the meetings, remote participation facilities, coordination of activities and productive interactions with subject matter experts increases based on the number of individuals participating in the proceedings. This means increased staff costs as well as increased time required from the Review Team members to organize and conduct their work.
A number of useful strategies can be applied to manage resources prudently while ensuring that the reviews proceed in an open and transparent manner with opportunities for the community to engage and provide feedback. For example observers could be invited to listen in to teleconferences with listen-only lines, and it should be possible for observers to be present during a physical meeting, but without travel funding support. Meetings should also be recorded and transcribed for ease of access to anyone interested in the work of the review team.
If the Review Team is able to restrict posting privileges and consensus calls, the remaining concern is related to how to handle sensitive or confidential information. This may arise in the Review Team on Security, Stability and Resiliency (SSR) for example, where there may be concerns with broadcasting publicly areas of SSR weakness or potential mitigation tactics. While some practices from cross-community working groups may be positive and appropriate for review teams to adopt, there are fundamental differences between AoC Review Teams and cross-community working groups, and there is a need to be careful not to conflate the two.
o Exact trigger points for the commencement of reviews without taking into account the Community bandwidth, or the state of pending implementation activities.
Reply: This regards a paragraph on each of the 4 AoC reviews "shall be convened no less frequently than every five years, measured from the date the previous review was convened." CCWG took into account community bandwidth concerns when we proposed that AoC reviews occur every 5 years — instead of the 3-year interval required in the AoC. We phrased the proposal to give flexibility for reviews to occur sooner than 5 year intervals. But we felt strongly that reviews need an interval requirement in order to ensure the reviews are not deferred indefinitely.
On the importance of flexibility: The Board agrees that reviews should not be deferred indefinitely and supports a review cycle that ensures predictability and regularity of reviews. We would like to point out that the specificity of the current AoC language led to the current situation where 3 AoC reviews were to commence simultaneously (CCT, WHOIS and SSR) in 2015. The Board reacted to Community concerns about volunteer workload by deferring two of the reviews to start in 2016 on a staggered basis. Exact trigger points that are hard coded into the Bylaws would take away this flexibility to adjust the schedule.
On the challenges of ascertaining the appropriate time for triggering reviews: A key aspect of subsequent reviews is to look at whether improvements that resulted from the past review recommendations have been effective in addressing the finding. This assessment can be difficult in situations where not enough time is available to operationalize the improvement and determine its effectiveness, especially in cases where implementation projects are complex and lengthy. When the next review is triggered such factors should be taken into consideration in order to use community and ICANN resources responsibly*, *while still allowing ICANN to meet its Bylaws obligations and providing predictability on when those reviews will commence.
b) To accommodate differing needs of reviews, the Board recommends leaving the number of review team members to the selectors of a specific review team, as to prescribing a specific formula for composition. This could leave to the selectors the flexibility, for example, to include more members from a specific SO or AC that is more impacted by a specific review, without hardcoding numbers into the Bylaws that might need to be changed later.
Reply: We are proposing a maximum of 21 members, based on community experience with previous reviews and data provided by staff on the number of members proposed by the community. We proposed 21 in order to accommodate each of the 7 AC/SOs having up to 3 members. We anticipate that some ACs and SOs will not offer 3 names, and have given the AC/SO chairs flexibility to give those member slots to an AC/SO that had higher interest and offered more than 3 candidates (per a comment from GNSO CSG).
Please refer to the responses above.
c) The Board is concerned with the CCWG-Accountability's recommendations on determinations of how consensus is applied.
Reply: This comment regards para 57: "If consensus cannot be reached among the participants, consensus will be sought among the members. In the event a consensus cannot be found among the members, a majority vote of the members may be taken. " CCWG proposed this text to ensure that Review Teams work in a predictable method that is consistent with cross community working groups in the ICANN context.
On possible limitations to adopting CCWG practices/method: While there are certain similarities between a Review Team and a cross-community working group, a Review Team is not designed to operate in the same way as a cross-community working group. While the Board supports allowing observers to review teams, asking for consensus calls among these observers requires a level of participation that would impact the Review Team's productivity.
Review Teams tackle difficult issues such as WHOIS, and evaluation enhancement of competition, consumer trust and choice through the introduction of New gTLDs. They are expected to develop concise, actionable and prioritized recommendations on these complex issues through members that have been vetted and endorsed by the SOs and ACs as having the requisite knowledge, experience and skills to contribute to the review. Including observers in broader consensus calls could frustrate the targeted work that the review teams are expected to achieve.
Imposing Bylaws requirements on allowing participants and observers, or requiring consensus calls are other examples where trying to hardcode specific requirements for reviews now might actually develop reviews that are less efficient, more resource intensive, and detract from the responsibilities of the review teams.
The Board notes that the ICANN community would benefit from a review schedule that would take into consideration community bandwidth and ICANN resources in developing a staggered or phased review schedule. These factors should determine what a workable number of concurrent reviews would be and ensure that no more than that number of reviews are scheduled at the same time.
Finally, the Board would like to highlight the work that has been underway within ICANN towards improving review effectiveness so that the CCWG and the community may factor this work in the development of operational standards. Work has been underway on the development of Operational Standards since last year, originating from ATRT2 recommendation 11 to improve effectiveness of Reviews together with Board Resolution 2015.07.28.14. In July 2015, after factoring public comments, the Board endorsed the proposed process and operational improvements designed to simplify and increase the effectiveness of Reviews. The Organizational Effectiveness Board Committee is currently working to finalize Policies, Procedures and Guidelines for the Organizational Reviews mandated by the Bylaws.
Reply: We note that the drafting being done by the board is for Organizational reviews — not the AoC reviews. Still, CCWG is open to consider the board's specific operational improvements as part of the implementation of CCWG's proposal. If possible, could you circulate to CCWG the current draft of these policies, procedures, and guidelines?
The standards are intended to apply to both AoC Reviews and Organizational Reviews. There are similarities between the two as well as lessons learned from prior reviews that apply to both. Previous public comments and Board discussions have been focused on standardization across the two types of reviews.
Work on compiling review-relevant information is ongoing by Staff with the goal of creating a single comprehensive resource that provides both a high-level overview as well as detailed operational information/guidelines. The user-friendliness of this resource is currently limited. There is a need to improve it with community input as Operational Standards provide best utility when they are continuously updated based on community needs and lessons learned, and are provided in an easy to use format.
We propose the following approach: Staff will share the listing of topics to be addressed by Operational Standards and the community will be asked whether they would support putting together a Working Group to work with Staff on developing the detailed Standards.
Other planned steps in the refinement of the operational standard include: Sharing information with the CCT Review Team as a pilot for utilizing Operational Standards and gather their feedback; Gathering feedback from former Review Team chairs and interested members; Implementing surveys at the end of each Review to gather feedback on how to improve the process; Holding webinars and other community engagement sessions for additional feedback; Creating a wiki space for interested community members to see work in process and offer feedback and suggestions; Developing an easy to use interactive means of navigating Operational Standards for improved clarity, transparency and understanding.
END
Board Comments on Recommendation #11 — GAC Advice
28 January 2016
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2016-January/010129.html
Here are the current Board comments on Recommendation 11 (GAC Advice):
The Board provides the following comments on Recommendation #11:
- The Board supports the consensus text included in the Third Draft proposal on the acceptance of GAC advice.
- The Board understands that this recommendation was not intended to impose any new requirements for the Board to take decisions on GAC advice, and that this issue can be addressed in the Bylaws drafting notes by indicating that the Board should not be obligated to act on all GAC advice through a vote.
- The Board supports that ACs should be required to provide rationale to accompany advice. The Board understands the CCWG recommendation to place an obligation on the Board, when taking a decision on a piece of advice, to consider whether the Board found the rationale sufficient. The Board would always be in a position to indicate if additional information is needed prior to completing consideration of any piece of advice. The Board does not consider this recommendation to impose a requirement that the Board must provide a specific determination for each piece of advice received regarding whether the Board felt the rationale was sufficient, and urges the CCWG to clarify for Bylaws drafting that the Board is not required to make a determination on whether every piece of formal advice has adequate rationale.
- The Board agrees with the CCWG-Accountability's clarification that, if the Board takes action inconsistent with the Bylaws – even if that action is based upon following the advice of an AC – the Board can be subject to an IRP. To the extent that the CCWG believes that it is important to specifically identify this in the Bylaws, the text used should apply to all Advisory Committees, and not solely refer to the GAC.
Cheers,
Chris Disspain
Board Comments on Recommendation #10 — SO/AC Accountability
28 January 2016
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2016-January/010128.html
All,
Here are the current Board comments on Recommendation 10 (SO/AC Accountability):
The Board continues to support this recommendation, and the importance of a focus on SO/AC accountability in light of the community empowerment recommended by the CCWG. The Mutual Accountability roundtable is a welcome innovation.
The Bylaws-mandated independent structural review of various ICANN bodies, known as Organizational Reviews, will continue to have an important role in assessing SO/AC Accountability. The Board has strong concerns surrounding the details In Recommendation 10 on these reviews, particularly in how the recommendations might not uphold the import of independence as the key facet of that work. Reviews are a mechanism to hold ICANN accountable and transparent, but also a means of inspiring a culture of continuous improvement. Independence and objectivity are essential ingredients of effective performance assessment.
- On the proposal that independent reviews should be commenced at the request of a majority of the SO/ACs rather than by the Board - the current process is instrumental in ensuring accountability: a regular, predictable review cycle that is not left to the discretion of the group to be reviewed is necessary to maintain accountability. The initiation of these reviews should be on a predictable cycle, and the proposal on the table leaves the possibility that a review might never commence.
- The CCWG draft document also suggests that recommendations should be approved only by the SOs/ACs acting through the community forum. This removes the Board's role in approval of recommendations, and could undermine the independence and accountability implicit in the current process. While there could be a mechanism to better involve the voice of the group under review, the Board plays an important role to preserve the independence of reviews and ensure that the group under review remains accountable.
- The CCWG also suggests that the reviews should happen in two phases – a self-assessment by the group under review, and then the independent examination after that self-assessment is completed. Self-assessments by the group under review serve as an important and valuable input into the independent examiner's work. The self-assessment, however, cannot be the sole focus of the independent examiner's work. It is essential the independent examiner reach his/her own conclusions to preserve objectivity, impartiality and independence – qualities essential to an effective review process.
Thank you
Cheers,
Chris Disspain
Board Comments on Recommendation #6 — Human Rights
26 January 2016
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2016-January/010013.html
Hello All,
Markus gave a verbal summary of the current position of the Board following our Board call yesterday during the CCWG call. I have set out the current position in writing below.
I recognize that the CCWG members did not accept the Board's position. There are quite a few Board members on the call - and we can take this discussion back to the Board to see if we can find another solution.
- The Board is committed to upholding human rights as appropriate within ICANN's mission; and
- The Board intends to work alongside the community to progress the human rights work within ICANN, including through the development of a Human Rights Statement to reach a meaningful framework to guide human rights considerations within ICANN's mission.
The Board still remains supportive of Option B, or allowing the WS2 effort on defining a framework to proceed prior to considering whether to include a human rights obligation in the Bylaws.
The Board understands that one of the reasons for the suggestion of a "dormant" bylaw text (which the Board remains concerned about for the reasons flagged earlier) is that there is concern among the community that if a reference to human rights is not included in the Bylaws, the Board will not follow through on a community wish to address this issue. To address this concern, the Board proposes that including in the Bylaws a requirement for ICANN to address the human rights issue, as well as a requirement to consider - after a framework is concluded - how that should be referenced in the Bylaws. The Board therefore proposes the following:
In the Bylaws text referencing WS2, language should be included that specifically identifies that a recommended framework on human rights within ICANN is expected to be part of the WS2 effort. Further, the Bylaws on WS2 should specify that If the cross-community group developing the framework also makes a consensus recommendation on whether and how that framework can be reflected in the ICANN Bylaws, the ICANN Board must consider that recommendation according to the process defined for considering those continuous improvement recommendations.
Regards,
Bruce Tonkin
ICANN Board Liaison to the CCWG
Board Comments on Recommendation #9 — AOC Reviews
26 January 2016
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2016-January/010014.html
Hello All,
Board Comment - Recommendation 9:
As noted in its comments on the third draft proposal, the Board supports the incorporation of the AOC reviews into the Bylaws, while noting the importance of maintaining operational standards for reviews outside of the Bylaws. While the Board agrees that operational standards should be in alignment with the provisions of the Bylaws, the Board views operational standards as a more suitable place to address multiple review-related operational items that do not belong in the Bylaws.
There are a few specific areas that the Board is flagging in relation to the operational standards -
- The Board is concerned about potential constrains that may limit flexibility and effectiveness in the operational standards and that certain CCWG-Accountability recommendations may not be aligned with best practices or industry standards, including:
- Fixed numbers of total review team members, as well as a fixed allocation among SO/ACs, without consideration of specific issues and required expertise for a given review.
- Unlimited number of participants, in addition to the appointed review team members, potentially affecting the team's productivity.
- Exact trigger points for the commencement of reviews without taking into account the Community bandwidth, or the state of pending implementation activities.
- To accommodate differing needs of reviews, the Board recommends leaving the number of review team members to the selectors of a specific review team, as to prescribing a specific formula for composition. This could leave to the selectors the flexibility, for example, to include more members from a specific SO or AC that is more impacted by a specific review, without hardcoding numbers into the Bylaws that might need to be changed later.
- The Board is concerned with the CCWG-Accountability's recommendations on determinations of how consensus is applied. Imposing Bylaws requirements on allowing participants and observers, or requiring consensus calls are other examples where trying to hardcode specific requirements for reviews now might actually develop reviews that are less efficient, more resource intensive, and detract from the responsibilities of the review teams.
The Board notes that the ICANN community would benefit from a review schedule that would take into consideration community bandwidth and ICANN resources in developing a staggered or phased review schedule. These factors should determine what a workable number of concurrent reviews would be and ensure that no more than that number of reviews are scheduled at the same time.
Finally, the Board would like to highlight the work that has been underway within ICANN towards improving review effectiveness so that the CCWG and the community may factor this work in the development of operational standards. Work has been underway on the development of Operational Standards since last year, originating from ATRT2 recommendation 11 to improve effectiveness of Reviews together with Board Resolution 2015.07.28.14. In July 2015, after factoring public comments, the Board endorsed the proposed process and operational improvements designed to simplify and increase the effectiveness of Reviews. The Organizational Effectiveness Board Committee is currently working to finalize Policies, Procedures and Guidelines for the Organizational Reviews mandated by the Bylaws.
Regards,
Bruce Tonkin
ICANN Board Liaison to the CCWG
Board Comments on Recommendation #3 — Fundamental Bylaws
23 January 2016
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2016-January/009870.html
Hello All,
On the Fundamental Bylaws (Recommendation 3), the Board has the following comment following the first reading:
The Board is supportive of the changes reflected in the document after the first reading. The Board notes that while it is supportive of the inspection right being reflected as a Fundamental Bylaw, the inspection right should be noted as a right of the community, and not of the Sole Designator, to align with the Board's comments on Recommendation 1.
Regards,
Bruce Tonkin
ICANN Board Liaison to the CCWG
Board Comments on Recommendation #2 — Escalation Timeframes
23 January 2016
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2016-January/009869.html
Hello All,
On Escalation Timeframes (Recommendation 2), the Board has the following comment following the second reading:
The Board reiterates its support for the modifications to the escalation timeframes, as well as flexibility within those procedures, so long as the timeframes and procedures allow the community to socialize the issues appropriately. The Board is supportive of the proposed times for the steps as reflected in the document produced after the second reading.
The Board is supportive of the language at paragraph 50, as well as the removal of paragraph 51 (which were previously paragraphs 62 and 64, respectively, as discussed in the Board's comments after the first reading) and believe that the removal addresses the concern that the threshold for the removal of the entire Board will not fall below four SOs or ACs.
Regards,
Bruce Tonkin
ICANN Board Liaison to the CCWG
Board Comments on Human Rights, IRP, and Community IRP
19 January 2016
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2016-January/009735.html
The Board appreciates the work by the community on the first readings of reactions to the public comment on the Third Draft Proposal from the CCWG-Accountability. In preparation for the second reading, the Board provides these inputs to the CCWG-Accountability on inclusion of Human Rights in the Bylaws, Scope of IRP and Scope of Community IRP.
On Inclusion of Human Rights in the Bylaws, the Board has the following reactions to the points identified in the redline distributed after the first reading before the CCWG.
The Board notes the continued discussion of this issue on the CCWG-Accountability list, and that there continues to be some divergence among the CCWG-Accountability on how to proceed among the options presented. As noted in its comments to the Third Draft Report, the Board remains committed to developing a Human Rights Statement for ICANN, and will report to the community at ICANN 55 Marrakech on progress on this work. The Board appreciates the import of this issue to the ICANN community, and remains committed to working alongside the community towards a meaningful framework to guide human rights considerations within ICANN¹s mission.
Regarding inclusion in the ICANN Bylaws, the Board supports Option B, or allowing the WS2 effort on defining a framework to proceed prior to considering whether to include a human rights obligation in the Bylaws.
The Board appreciates the consideration the CCWG-Accountability has given to the timing concerns raised by the Board in its comments. Of note, the Board¹s concerns in introducing a human rights consideration in its Bylaws today prior to the completion of a framework was not the only concern raised. The language presented by the CCWG-Accountability for the Bylaws also raised concerns. As stated in the Board¹s comments:
While the Board appreciates that the proposed interim Bylaw text is intended to not place any additional obligations on ICANN, the language could actually be used to greatly expand ICANN¹s human rights obligations. Some specific examples of concern include:
- Inclusion of a human rights commitment in the Bylaws would immediately allow for IRPs to be brought on human rights grounds. Similarly, there could be lawsuits relying on the Bylaws language filed against ICANN. When the Bylaws commitment is vaguely stated, any interpretation of the Bylaws language will be against ICANN, and have binding impact on the community's ability to define a framework. Neither the IRP or the Courts will have any legal reason to wait for the community to complete the next step, and could make their own interpretations of the language.
- The proposed Bylaws text, with reference to "applicable law" to judge the acts of ICANN and those with relationships with ICANN, leaves open the question of which law should be applicable. This language expands, as opposed to limits, the potential scope of human rights challenges.
- The language about "any entity having a relationship with ICANN" raises the suggestion that the ICANN Bylaws have the power to bind those with relationships with ICANN in how those entities respect, consider or enforce human rights. ICANN does not have this power. For example, registries and registrars contracted with ICANN do not take on any human rights obligations because they contract with ICANN. This language suggests that because they have a relationship with ICANN, there are human rights concerns that they could be obligated to address.
- The language suggests that there is already a framework within which ICANN processes complaints, requests or demands for ICANN to enforce human rights issues, which there is not. Indeed, there still appears to be divergence within the community about what should be considered as human rights considerations within ICANN¹s Mission. Without a framework, challenges could be raised around issues that are not agreed to be within ICANN's Mission, such as access, content or education.
Leaving these types of issues open puts the community, ICANN stakeholders such as contracted parties, and ICANN itself at risk. Courts or binding IRP panels could be used to create precedent defining what human rights are within ICANN¹s Mission. These determinations are better left for the ICANN community to sort out, instead of being imposed. Leaving these questions open for others outside of the ICANN community to define is not consistent with enhancing ICANN's accountability. The Board urges that the full scope of defined work on human rights should include consideration of impacts across all of ICANN¹s activities.
As noted by ICANN's legal counsel, the concern raised by the Board is not primarily about an increase in the potential litigation across ICANN, but rather about the impact of that litigation on the ICANN community, in the potential to define ICANN's human rights obligations before the community has the opportunity to complete that work. The proposed limitation of applicable laws does not provide much comfort, as there are no limitations of which laws will be suggested to be applicable to which parties. This is not a trivial concern. Which court and which law will be relied upon to decide if human rights includes a requirement to make all registrant data public in an attempt to protect against abusive content on websites? Or which court and which law will be relied upon to require all registrant data to be made private to recognize privacy interests or the potential impact to third parties with which ICANN does business? It is examples such as these that demonstrate why the ICANN community needs to weigh in on where ICANN¹s human rights obligations start and stop, before a court is invited to make those determinations.
Recommendation 7, Scope of IRP:
The Board previously expressed concerns about the IRP being used for substantive appeals from process-specific expert panels, and notes the apparent agreement on the CCWG-Accountability to remove the expert appeals language from the scope of the IRP. Even with this removal, the Board notes that any violation of the ICANN Articles of Incorporation or Bylaws that occurs in conjunction with the consideration of an expert panel can appropriately be the basis of an IRP. The Board has the following additional comments:
- The IRP should not be used to determine what documents are to be released as part of ICANN's Documentary Information Disclosure Policy (DIDP). If a DIDP response is in violation of ICANN¹s Bylaws/AoI, then an IRP can lie on the grounds of a Bylaws/AoI violation. The Board notes that a more substantive appeal process for the DIDP could be developed as part of the DIDP review in WS2. The development of a substantive DIDP appeal process was not previously identified as a WS1 effort.
- The Board supports the CWG-Stewardship contingency that the IRP is made available as part of the accountability for the performance of the naming function work by PTI. The implementation of this must be done carefully so as to not confuse ICANN's obligations with PTI's obligations.
- The Board also supports the request from the IAB that the protocol parameters are excluded from the IRP.
- The Board notes that there should be a broad range of participants for the work of the IRP implementation team (including jurists and those versed in international arbitration).
- The Board discourages the use of exemptions to the already limited world of "loser pays" outcomes of IRPs, such as a proposed exemption for non-profit entities, as there should not be incentive for a certain group of complainants to more easily bring IRPs if they are not faced with the potential recourse for bringing IRPs on suspect grounds.
Recommendation 4, Scope of Community IRP:
The Board reiterates its concerns regarding the inclusion of expert panel appeals and substantive DIDP appeals, as stated in regards to Recommendation 7.
The Board appreciates the community discussion regarding a carve-out of the Community IRP as it relates to PDP outcomes. The Board notes that, particularly with a threshold of 3 SOs or ACs, there other potential for the filing of a Community IRP to pit parts of the community against other parts of the community, such as countering the Board¹s acceptance of advice from Advisory Committees. The Board encourages the CCWG-Accountability to see if there are additional protections that can be introduced so that community resources are not used to challenge properly taken actions from another part of the community.
Board Comments on Recommendation #4 — IANA Budget
14 January 2016
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2016-January/009586.html
Hello All,
The Board supports the revisions provided in the 1st reading document of the CCWG for this provision. The addition of language reflected in paragraph 21 addresses the Board's comments and concerns that any process through which a portion or the whole of the IANA budget is subject to rejection must include the voice of the operational communities served by the IANA functions. Additionally, the Board supports the inclusion of the process ensuring the stable and continuous delivery of the IANA Functions, and proper delivery of contractual service levels to the respective operational communities.
With regards to the caretaker budget (reference in paragraph 13) the Board wants to remind the CCWG of its comments on the ICANN Caretaker budget, and the recommendation that the whole of the caretaker budget approach is 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 proposal can be found on page 10, paragraph 1e of its comments. The language in the redline could be read as a commitment to only include caretaker budget considerations for the IANA budget. Copied here for convenience:
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.
Regards,
Bruce Tonkin
ICANN Board Liaison to the CCWG
Board Comments on Recommendation #2 — Escalation Timeframes and Thresholds
14 January 2016
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2016-January/009584.html
Hello All,
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)."
Regards,
Bruce Tonkin
ICANN Board Liaison to the CCWG
Board Comments on Recommendation #1 — Inspection Rights
14 January 2016
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2016-January/009583.html
Hello All,
First, the Board agrees with an inspection right that limited to accounting books and records. The Board also agrees that the inspection right can be invoked by a single SO or AC. The inspection right, however, does not need to be a right reserved to the Sole Designator. As explained in the Board's Comments on the Third Draft Proposal, the inspection right should be a community right, and not a right reserved to the Sole Designator. Giving the Sole Designator a right of inspection - as opposed to making it a right held by the community - represents a significant and inappropriate change to the Sole Designator. The Sole Designator can be used to enforce the community's right of inspection (through the escalation process, if ICANN errs in response). Particularly when a single SO or AC could invoke the inspection right, requiring that demand to go through a community process to direct the Sole Designator seems to add complexity that is not necessary.
The Board therefore recommends changing the words of Paragraph 20 to "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."
For 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 the demand on the Board, requiring community consensus."
The Board agrees with the inclusion of an investigation right, and notes that the language proposed in the redline reflects the Board's comments.
Finally, 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.
Regards,
Bruce Tonkin
ICANN Board Liaison to the CCWG
Board Comments on Recommendation #12 — Work Stream 2
12 January 2016
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2016-January/009503.html
Hello All,
The Board discussed recommendation 12 in the Board information call today, and offers the following response:
First, the Board agrees that a transitional bylaw can be used to define the Board's commitment on WS2 matters. Second, the effort anticipated in WS2 should be performed through cross community working groups chartered by multiple groups across ICANN, effort and not all work must be done by the existing CCWG-Accountability. Third, the Board agrees that it will treat consensus based-recommendations on the limited list of WS2 topics (set out in the CCWG-Accountability's redline) just as it will consider the consensus-based WS1 recommendations from the CCWG-Accountability. Fourth, the Board does not support the inclusion of a timeline for the required completion of WS2 efforts in the transitional Bylaw. Finally, the Board supports that the costs of WS2 must be subject to the budgetary process for the year. If the budget is exhausted and additional resources are necessary, the chartering organizations must support a request for Board consideration on additional funding.
Regards,
Bruce Tonkin
ICANN Board Liaison to the CCWG
Board Comments on Recommendation #4 — Board Removal Liability Mitigation
12 January 2016
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2016-January/009502.html
Hello All,
The Board discussed recommendation 12 in the Board information call today, and offers the following response:
The issue of potential liability to community members for action taken during the Board removal process raises some concerns for Board members, particularly around the suggested mitigation of using pre-service letters to obtain waivers from Board members that they will not sue community members for conduct in the Board removal process. The Board does not support the use of a waiver clause in pre-service letters (or the full indemnification clause), making service on the Board subject to waiving any manner of conduct from a large group of potential actors. That does not seem to enhance accountability.
The Board notes the CCWG-Accountability's insertion of a requirement to subject both NomCom and AC/SO appointed directors to the same process (including conversations with the Board Chair), as well as highlighting the need for consideration of independence in selecting replacement directors. Additionally, the Board notes the CCWG-Accountability insertion of a requirement for a written rationale to accompany a Board member removal petition. As some in the CCWG-Accountability have appreciated, the Board's statement that rationale should be presented is not an attempt to predefine the conditions for removal.
Regards,
Bruce Tonkin
ICANN Board Liaison to the CCWG
ICANN Board Comments on Third CCWG-Accountability Draft Proposal on Work Stream 1 Recommendations
14 December 2015
Original posting: http://forum.icann.org/lists/comments-draft-ccwg-accountability-proposal-30nov15/msg00013.html
The Board appreciates the opportunity to provide comments on the Third CCWG-Accountability Draft Proposal on Work Stream 1 Recommendations as part of the CCWG's process. The Board is pleased with the extent of agreement within the CCWG reflected in the Third Draft Proposal, and expects that the input by the SOs and ACs, and the broader community, during this final public comment phase is important to finalize a consensus document. In line with the CCWG Chairs' communication to the SO and AC leadership, the Board is sharing its comments with the respective SOs and ACs, in addition to filing them with the CCWG.
In these comments, the Board expresses its agreement and support for nearly all of the recommendations in the Third Draft Proposal. For areas where the Board has remaining concerns consistent with what it has raised, including in response to the 15 November Summary, we provide recommendations and suggestions for addressing the concerns.
The Board has reviewed the Proposal and provides its feedback also in view of the 16 October 2014 resolution, identifying areas where the Board is concerned that the Final Report may include recommendations for which the specifics may need to be reviewed for meeting the global public interest. For all the comments, in particular where there are proposed solutions, the Board has provided its rationale for the positions.
As noted above, the Board believes the governance and accountability portions of the proposal are sound and we are in almost complete agreement with those recommendations. Where the recommendations are on issues of redefining the scope of ICANN's commitment (such as on the mission statement or human rights), the Board fundamentally agrees with the need for change, but has some specific suggestions to ensure that ICANN is responsible to and conscious of its mandate. Some of these matters need to be addressed as part of the final report while others can be addressed in bylaw implementation.
Areas of greater concern are on scope and implementation of inspection rights (a part of Recommendation 1); veto of the IANA budget (a part of Recommendation 4); contractual enforcement in the Mission statement (a part of Recommendation 5), integration of human rights considerations (Recommendation 6), and specifics for WS2 (a part of Recommendation 12). Specifics of the Board's comments are reflected in the attached document. In summary, they are:
- Recommendation 1: The Board Supports the Establishment of the Empowered Community including the Sole Designator Model with Powers of Board Appointment, Removal, and Enforcement
- Inspection Rights: With regards to inspection rights, the Board also agrees to Inspection Rights for the Community that are Well-Defined
- Recommendation 2: The Board Supports This Recommendation and Suggests Further Defining the Thresholds
- Recommendation 3: The Board Supports This Recommendation
- Recommendation 4: The Board Supports the Community Powers. With regards to specific community powers:
- The Power to Reject ICANN's Budget or Strategy/Operating Plans: The Board recommends a Clarification to Both the IANA Budget and ICANN Caretaker Budget
- The Power to Reject Changes to ICANN Standard Bylaws: The Board recommends clarifying the Interrelation of Policy-Related Bylaws Changes
- The Power to Remove Individual ICANN Board Directors: The Board recommends the process include a Clear Rationale
- The Power to Recall the Entire ICANN Board: The Board Supports this Recommendation, and recommends Maintaining High Thresholds o The Power to Approve Changes to ICANN Fundamental Bylaws and Articles of Incorporation: The Board Supports This Recommendation
- The Power to Initiate a Binding Community Independent Review: The Board recommends a Clear Demonstration of Community Support
- The Power to Reject ICANN Board Decisions Relating to Reviews of IANA Functions, Including Triggering of Post-Transition IANA Separation: The Board recommends a Clarification of Footnote 5
- Recommendation 5: The Board Supports the Recommendations On Core Values and Commitments.
- Mission Statement: The Board Supports Modifying the Mission Statement with an Emphasis on Clear, Concise Language
- Recommendation 6: The Board Supports Integrating Human Rights Considerations in ICANN, with Clear Timetable to Define Human Rights Framework
- Recommendation 7: The Board Supports this Recommendation but Requests Enhancements to Uphold the CCWG-Accountability's Stated Purpose of the IRP
- Recommendation 8: The Board Supports This Recommendation
- Recommendation 9: The Board Supports This Recommendation
- Recommendation 10: The Board Supports This Recommendation
- Recommendation 11: The Board Supports This Recommendation
- Recommendation 12: The Board Supports Further Accountability Work And Confirms Commitment to How It Will Consider Further Recommendations
Detailed specifics, including rationale, are reflected in the Board comments. We are sending our comments in advance of the end of the public comment period for consideration by the CCWG with the other comments received, and also communicating them to the SOs and ACs so that these may be considered in their approvals as Chartering Organizations of the CCWG-Accountability.
We look forward to receiving the Final Proposal, and for the entire community coming together to finalize Work Stream 1 of the Enhancing ICANN Accountability process. We are at a historic time in the transition of the IANA Stewardship functions to the global multistakeholder community.
Sincerely,
Dr. Stephen Crocker
Chair, ICANN Board Of Directors
Joint Meeting of the ICANN Board & CCWG-Accountability co-Chairs
13 December 2015
Original posting: https://www.icann.org/en/system/files/files/transcript-icann-board-ccwg-co-chairs-13dec15-en.pdf [PDF, 130 KB]
Update on Board Discussions on the CCWG-Accountability Summary Document
24 November 2015
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2015-November/008390.html
Hello All,
As noted last week, the Board has been considering the CCWG Update on Progress Made In and After ICANN54 in Dublin published on 15 Nov 2015.
The Board is preparing for the Public Comment period on the Third Draft Proposal, and intends to submit its comments on the Third Draft Proposal by mid-December.
The Board thought it may be useful to share some initial comments based on the information in the CCWG Update.
For ease of reference, the page number in the Update Document has been included for each item below.
-
Human Rights (pages 25-26)
The Board is committed to upholding human rights as appropriate within its limited Mission and scope of responsibilities. We appreciate the community's interest in reflecting human rights in the ICANN Bylaws, but we remain concerned that the placement of such language into the Bylaws requires full consideration of the impact of that language across all of ICANN's activities. We note that a potential approach is for a group to develop a Framework of Interpretation as part of Work Steam 2. It is important that this topic has comprehensive community discussion, including impact on policy development and identification of how those developing policy recommendations should consider human rights within their work, as well as any implications such as on ccTLD re-delegations. Any final formulation of human rights must not extend ICANN's limited mission and scope of responsibilities.
-
Inspection Rights and Transparency (page 12)
The Board remains concerned about the insertion of inspection rights premised on the fact that they would have been available under a member structure. The Board has already agreed that the issues of transparency, including a review of the DIDP and assessment of what additional information (such as financial information) should be made publicly available, is an item for further work. In the Board's view, prior to the development of an inspection right, consideration should be given to what sort of information is expected to be requested, for what purpose and by whom. Further, to address the concerns over increased financial transparency, the Board will be proposing a methodology during the upcoming public comment period through which an independent audit can be initiated, and has instructed staff to start considering how additional financial transparency can be achieved.
-
Removal of the Board (individual/entire) (pages 21-23)
The Board believes that the rationale for the removal of the entire board or an individual Board member must be clearly set out, for example, through reference to a cause for removal that could be set out in a pre-service letter.
Additionally, the Board strongly believes the threshold for the removal of the entire board should not go below a total of four SOs and ACs in support of removal.
-
Board Consideration of GAC advice (page 34)
The Board will continue to monitor the discussions. We note that any solution should include a provision that, in the event of the rejection of GAC advice, the Board is only required to enter into a formal consultation process where the GAC advice is consensus advice based on the current definition within the GAC's Operating Procedures (which relies on the UN definition of consensus). The Board values receipt of consensus advice as reflected in the current GAC Operating Procedures. Since the first ATRT, there has been a lot of effort made to clarify what "GAC Advice" means and does not mean within GAC Communiqués. Care should be taken not to introduce language into the Bylaws that reduces that clarity and returns the Board to a position of having to negotiate among various positions in its consultation processes.
-
Sole Designator Model (page 11)
The Board supports the Sole Designator model with the understanding that limited powers of appointment, removal and enforcement are maintained as the guiding principles for this model.
-
AoC Reviews and Implementation Factors (page 31)
The Board appreciates the work to incorporate the AOC reviews into the Bylaws and reiterates as a principle that operational/administrative details not be inserted into the Bylaws, in favor of defined standards for such reviews that can be changed (with community participation) through processes that do not require Bylaws changes.
-
Community Decision-Making Power (page 12)
The Board believes it is important that the Community Decision Making Power has appropriate thresholds that are defined in ways that reflect a community decision, and are flexible enough to allow entrance (or exit) of existing or new SOs or ACs.
Regards,
Bruce Tonkin
ICANN Board Liaison to the CCWG
Board Comments on Mission Statement
19 November 2015
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2015-November/008166.html
Hello All,
The Board has been considering the CCWG Update on Progress Made In and After ICANN54 in Dublin published on 15 Nov 2015.
The Board information call today considered the changes to the mission statement identified in that update.
Attached is the Board's preliminary comments on the mission statement part of the Dublin update report. As we review the remainder of that Update, we'll send through additional comments.
For ease of reference, the page number in the Update Document has been included for each item below.
Regards,
Bruce Tonkin
ICANN Board Liaison to the CCWG
Board Position on Work Stream 2
13 November 2015
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2015-November/007941.html
Hello León, Mathieu and Thomas,
Thank you for your note and request to confirm the support for WS2.
The Board supports the context and elements around the list of WS2 items, and the work of the community to address these points.
The Board will use the same approach to accepting the WS2 recommendations as those of WS1, including meeting the criteria set out by NTIA.
We look forward to working with you and the community on the mechanisms, and will provide appropriate support for the work on the WS2 issues.
Regards,
Bruce Tonkin
ICANN Board Liaison to the CCWG
Dublin and Transition
13 October 2015
Original posting: https://www.icann.org/news/blog/dublin-and-transition
I look forward to seeing many of you on the Emerald Isle at ICANN54. I personally have been reinvigorated witnessing the commitment of the community, the CCWG-Accountability in particular, as we work towards completing the last piece of a proposal that will move ICANN to an independent, improved and even more accountable organization.
We all know the reality of the situation we're facing today, not just the timelines but also the need to come together on this last piece of the puzzle. It's not about the Board, nor about any other single stakeholder – it's about the whole community coming together. As I've said before, though I and the other Board members are on the Board now, we are only here for a while, and then we will leave. In two years one of you will take over my seat and I will return to my former role in the wider community. We're all stakeholders – that's the beauty of the ICANN multistakeholder model. Everyone has a voice – and as soon as anyone says differently or tries to exclude people, well, that's not the Internet community I've participated in and watched evolve over the last 30 plus years, and that's not what ICANN is about.
It's about wading through a noisy, and at times robust, but good faith discussion to come together and agree upon a final, balanced approach. Right now, it happens to be about the CCWG-Accountability analyzing and addressing the 93 comments from the last round of public comment, listening to all possible views and opinions from across the community– including those that come forward in Dublin—and developing a final consensus proposal.
We are in the final stretch of this and it's time for everyone, however involved you've been, to help work towards a consensus.
Dublin will be key as we show the world what our multistakeholder model can accomplish. I know many on the Board are deeply engaged alongside many of you in the working parties and will continue participating in community discussion throughout this process. The CCWG and the broader community both have a lot of discussions ahead. The Board looks forward to participating as one stakeholder of many, and I thank you all for your energy and commitment to this effort. It really is a wonder to behold.
For those of you following the IANA Stewardship Transition and Enhancing ICANN Accountability processes in Dublin or from your computer at home, below is a quick reference guide to the latest transition-related meetings. At the community's request, the ICANN staff identified additional times for ICANN Accountability discussions with as little disruption as possible to the current meeting schedule.
Please don't hesitate to join in the discussions no matter where you are in the world. We are nearly there. It is a historic moment, and truly a testament to the strength of the multistakeholder model.
| Date | Time | Session Title | Room |
| Friday, 16 October | 08:30-18:30 | CCWG-Accountability Face-to-Face Meeting | Liffey H2 |
| Saturday, 17 October | 08:30-12:00 | CCWG-Accountability Sub-team Breakouts | Liffey H2 |
| Saturday, 17 October | 13:00-17:00 | ICG Face-to-Face Meeting | Liffey B |
| Sunday, 18 October | 09:00-12:00 | ICG Face-to-Face Meeting | Liffey B |
| Sunday, 18 October | 16:45-18:15 | Transition Perspectives: From Internet Pioneer and the U.S. Congress | Auditorium |
| Monday, 19 October | 10:15-11:45 | CCWG-Accountability Engagement Session | Auditorium |
| Monday, 19 October | 12:00-13:00 | ICG Engagement Session | Auditorium |
| Monday, 19 October | 14:00-18:30 | Discussion on Enhancing ICANN Accountability | Auditorium |
| Wednesday, 21 October | 09:30-11:00 | CWG-Stewardship Working Session | Wicklow H2 |
| Wednesday, 21 October | 15:30-16:30 | IANA Stewardship Transition Implementation | Wicklow H2 |
| Wednesday, 21 October | 17:00-20:00 | Discussion on Enhancing ICANN Accountability | Auditorium |
| Thursday, 22 October | 08:00-10:30 | CCWG-Accountability Working Session | Liffey H2 |
| Thursday, 22 October | 10:30-12:30 | ICG Working Session | Liffey B |
| Friday, 23 October | 09:00-17:00 | ICG Working Session | Liffey B |
Thoughts Heading into Los Angeles
24 September 2015
Original posting: https://www.icann.org/news/blog/thoughts-heading-into-los-angeles
The CCWG-Accountability chairs recently observed in a blog post how critical it is that we all keep up our energy and momentum going into the next CCWG-Accountability face-to-face meeting in Los Angeles on 25 and 26 September. I could not agree more. The CCWG-Accountability deserves much applause for its tremendous and impressive work leading to the 2nd Draft Proposal, this most recent public comment period and for its commitment to bring this process to a successful conclusion. It hasn't always been easy. The Board has tried to act in good faith throughout this process, weighing the most appropriate and helpful times to contribute, and in what manner in this unprecedented community effort.
The CCWG meeting in Los Angeles comes at a critical time. While it's easy to analyze the areas where consensus still needs to be reached, it is important to also recognize the many elements of the accountability proposal that have reached broad support. In studying the public comments, we agree with the CCWG that there are many areas of agreement and we look forward to contributing as a part of the community to refine and build upon the 2nd Draft Proposal to create the necessary enhancements to ICANN's accountability.
It is more important to get this work done right than it is to get it done quickly. However, should the group not focus on the core accountability requirements to fill the backstop role of the U.S. Government, I fear that it will drive the transition towards delay or even possible failure after being so close to completion. A lot of work has been done by our community, in the CCWG and at the ICG, and the crafting of these two dynamic proposals has been a testament to the capability of the multistakeholder community – we must not let this moment pass.
I am personally looking forward to using this time in Los Angeles to contribute constructively to the work of the CCWG and remain confident we will continue to enhance what we have built together.
ICANN Board Submits Final Comments to CCWG-Accountability Public Comment
11 September 2015
Original posting: https://www.icann.org/news/blog/icann-board-submits-final-comments-to-ccwg-accountability-public-comment
It has been a very busy week for many in the community, including the ICANN Board. Tuesday marked the conclusion of the ICG public comment period, which saw over 150 comments submitted. The ICANN Board submitted comments on the ICG Proposal, which can be found here [PDF, 133 KB].
Additionally, after weeks of extensive dialogue with the community, the ICANN Board has submitted its final input to the CCWG-Accountability 2nd Draft Proposal Public Comment forum. The Board is proceeding in accordance with the principles we outlined in our 2014 resolution addressing what the Board would do in the event it disagreed with a CCWG recommendation.
The elements of the Board submission are:
- A brief summary of its public comment input
- A comments matrix of forty-seven CCWG-Accountability proposal elements and their assessment by the ICANN Board
- A short memo describing a proposed approach for community enforceability for consideration
- A twenty-question FAQ of the proposed approach for community enforceability
As we have stated previously, the Board supports the improvements to ICANN's accountability contained in the CCWG-Accountability's 2nd Draft Proposal. We endorse the goal of enforceability of these accountability mechanisms, and we believe that it is possible to implement the key elements of the proposal. We want to work together to achieve the elements of the proposal within the community's timeline while meeting the NTIA requirements.
We have heard some concerns from the community regarding the Board's intent in presenting new ideas for the CCWG's consideration. The contributions by the Board are not meant to be a "counter proposal," but rather as suggestions for consideration to build upon the CCWG's impressive work. We encourage the community to read not only ours, but all comments submitted to the public comment forum. There are still 24 hours to submit comments on the proposal, and we encourage any interested stakeholder to do so.
Once again, on behalf of the Board, I want to thank the CCWG-Accountability for all of its work leading to the 2nd Draft Proposal and for its engagement throughout this significant process. This is an important discussion for the entire community as it reaches consensus, and we hope to continue this dialogue in Los Angeles later this month at the CCWG-Accountability face-to-face meeting.
ICANN Board Submission of Supplementary and Final Comments to the CCWG-Accountability 2nd Draft Proposal Public Comment Forum
11 September 2015
Original posting: http://forum.icann.org/lists/comments-ccwg-accountability-03aug15/msg00045.html
Summary of Board Input
The ICANN Board thanks the CCWG-Accountability for all of its work leading to the 2nd Draft Proposal and for the continuous dialogues and engagement throughout this significant process. This is an important discussion for the entire community as it reaches consensus.
With this submission, we provide supplementary and final comments to the CCWG-Accountability 2nd Draft Proposal Public Comment forum including:
- Comments Matrix and Notes
- Proposed Approach for Community Enforceability
- Frequently Asked Questions Regarding Approach for Community Enforceability
As we have stated previously, the Board supports the improvements for ICANN's accountability contained in the CCWG-Accountability's 2nd Draft Proposal. We endorse the goal of enforceability of these accountability mechanisms, and we believe that it is possible to implement the key elements of the proposal. We want to work together to achieve the elements of the proposal within the community's timeline while meeting the NTIA requirements.
We also agree with the CCWG-Accountability that it is important, in light of the changing historical relationship with the United States, that there are mechanisms in place to ensure accountability with appropriate checks and balances for the organization. We also recognize that this process has an impact on the whole global community and unique identifier ecosystem.
Specifically, the Board endorses elements of the 2nd Draft Proposal including:
- Developing Fundamental Bylaws that hold special protections;
- Specific requirements for empowering the community into the Bylaws adoption process;
- Enhancements to the Independent Review Process (IRP);
- Board and Director removal;
- ICANN's mission and core values;
- Empowering the community in the budget, operational and strategic planning processes;
- The incorporation of the Affirmation of Commitments Reviews into the ICANN Bylaws; and
- Enshrining in the Bylaws the community ability to enforce the accountability mechanisms.
We note the CCWG's 2nd Draft Proposal recommends changing ICANN's governance structure to a Sole Membership Model in order for the community to achieve enforceability of the accountability mechanisms listed above.
We support enforceability, but have serious concerns about switching the governance structure of the organization prior to transition.
In particular, we are mindful of Assistant Secretary and NTIA Administrator Larry Strickling's overarching criteria and his remarks in Buenos Aires that the proposals must be simple, with no gaps and that complexity may add implementation delays.
In this regard, there are aspects of the proposed structure that concern us, which include:
- The proposed community enforceability structure introduces a significant and fundamental structural change from the current multistakeholder governance mechanism that the community has developed in a bottom-up consensus-based process over the past 17 years.
- Moving ICANN's structure away from an open, multistakeholder governance mechanism to the Sole Membership Model makes it more restrictive to a set of members, and potentially more prone to capture if not tested appropriately.
- The structural change to the Sole Membership Model may result in a change in balance of power in ways that cannot be predicted. The Member itself has no inherent checks, including potential influence by voting participants over others. We believe unnecessary complexity increases the possibility that we will collectively be unable to identify and mitigate all consequences of the new structure, including unknown risks caused by potential shifts in the balance of power between various stakeholder groups in the multistakeholder model.
- We are concerned with an increased risk of budget paralysis and instability, where strategic objections to one part of a budget could keep ICANN from moving to a budget that more appropriately supports its operations and efforts to maintain the security, stability and resiliency of the DNS.
We believe the Sole Membership Model as proposed has the potential for changes in the balance of powers between stakeholder groups in ICANN's multistakeholder model. At any time, the balance of power and influence among any of the "groups" within ICANN can change based upon the willingness or ability to participate in the Sole Member, changing for example the balance between governments and the private sector and civil society. We believe that if the Sole Membership Model is the only proposed path forward, it may be prudent to delay the transition until the Sole Membership Model is in place and ICANN has demonstrated its experience operating the model and ensuring that the model works in a stable manner.
We therefore suggest for consideration a different approach that achieves the community's goal of enforceability with a straightforward extension to our multistakeholder governance structure, which meets the NTIA criteria, while not opening up questions of stability, capture or diminishing of checks and balances.
The Board has proposed for consideration a Multistakeholder Enforcement Mechanism (MEM) that we believe delivers on the objective of the community to create an enforcement mechanism. The matrix and details of the suggested MEM are offered as a contribution to the public comment process. Again, the Board wants to ensure community enforceability within the framework of the continuously evolving ICANN governance structure. This builds on our initial thinking on a CCWG-Accountability Proposal Delivery Framework shared here: http://mm.icann.org/pipermail/accountability-cross-community/2015-September/005161.html.
The MEM is meant to be a suggestion for consideration to bring the significant amount of further and additional accountability the community has identified, while helping meet the NTIA criteria and using the tested structure we have today. The Board is absolutely not espousing status quo. We hear, accept and support the CCWG's goals of improving accountability and enforceability.
The Board welcomes the opportunity for further dialogue with and between the CCWG-Accountability as it considers all the public comments it receives. We hope that engagement on specific ideas will be a helpful path towards building upon the CCWG's work and to help reach consensus for a successful IANA Stewardship Transition and an ICANN with enhanced accountability. We remain very appreciative of the CCWG's valuable work.
ICANN Board Comment on the ICG Proposal
8 September 2015
Original posting: https://comments.ianacg.org/pdf/submission/submission121.pdf [PDF, 133 KB]
ICANN as the current IANA Functions Operator and facilitator of the IANA Stewardship Transition process welcomes this opportunity to provide comments on the ICG Proposal.
First and foremost, the ICANN Board would like to express its appreciation for the hard work done by the ICG members and the three operational communities to produce the ICG Proposal. The result of the work shows once again how a multistakeholder system works and the remarkable level of dedication of many volunteers around the world who are committed to the stability and security of the IANA Functions.
The main focus of the ICANN Board's comments is on the implementation of the proposals by ICANN as the current IANA Functions Operator. While the ICG has asserted that there are no incompatibilities between the three operational communities' proposals received (also known as the CRISP, CWG-Stewardship, and IANAPLAN responses), there are some implementation details and foreseen complexities that will need further coordination with the communities for clarity. As implementation occurs, ways to address the elements of the proposal may evolve, and in our comments below, we have endeavored to highlight some of these and provide the ICG with implementation suggestions.
We do not believe that any of these issues poses a threat to the viability of the final ICG Proposal. We hope that these implementation issues and details can be resolved in the implementation phase, but we urge the community and where needed the ICG to consider these issues and begin to clarify as soon as practicable in the interests of a smooth IANA Stewardship Transition.
Our comments address overlaps and shared resources where coordination among the three operational communities is an essential part of the solution. These include:
- New Service Levels and other Operational changes: The aggregate of the proposals enumerate a number of requirements that the operational communities expect to be completed in advance of the IANA Stewardship Transition. To implement these requirements, ICANN will need to change its existing systems, procedures and tools, and the implementation of these changes will impact day-to-day IANA operations. We would appreciate recommendations on how to prioritize the number of proposed development projects that compete for the same resource pool of staff. A clear identification of what needs to be completed before the transition, and what can be postponed to after the transition will be very helpful for a transparent implementation phase.
- Registry overlaps: In some areas, two or more operational communities jointly manage the IANA Functions. Examples of this include the IPv4 and
IPv6 space registries that serve both the RIRs and the IETF (for Special Purpose Address Space – c.f. RFC6890). This same concept applies to the name space where the TLD registry is shared between Accredited TLD registries and the IETF (for Special Purpose Reserved Names – c.f. RFC6761). Given a future possible scenario of a split of the IANA Functions, we note that these services may need to be split into separate registries. To ensure operational security and stability in case of a split, the operational communities will need to work with the IANA Functions Operator to agree on a clear transition plan framework that takes into consideration all possible overlap. ICANN commits to working with the operational communities should a transition be needed and welcomes the inclusion of any suggestions that may have already been discussed.
- Relationship between ICANN, PTI, and the operational communities: The ICG proposal introduces a new concept and structure for managing the IANA Functions through a new entity known as the Post-Transition IANA (PTI). The ICG Proposal implies that PTI will be providing all IANA Functions services to the operational communities (c.f. ICG FAQ question #5). In addition, the names community suggests an operational relationship directly with PTI, while the other two communities propose agreements directly with ICANN. The ICANN Board seeks more clarity on the implications of these arrangements on ICANN and ICANN's relationship with the operational communities.
- Process to determine a successor operator: In the case the IANA Functions are split, the ICG Proposal lacks detail on the process that each operational community will use to determine the escalation paths leading to separability, ensuring accountability of a successor, and identifying a successor IANA Functions Operator. The CWG-Stewardship response provided a framework that may be of use to the other operational communities in determining their processes (c.f. P1. Annex M).
We look forward to working with the ICG and the operational communities to clarify the process by which we would handle concerns raised during the comment period and/or the implementation phase.
The ICANN Board has been intently following the IANA Stewardship Transition and related Enhancing ICANN Accountability & Governance processes, and has submitted comments on operational community drafts before their submission to the ICG. Concerns raised in this comment on the ICG Proposal have also been raised in prior comments. For a comprehensive lists of all the ICANN Board's input into the processes, please see https://www.icann.org/resources/pages/board-input-stewardship-accountability-2015-07-10-en.
Upcoming Comments from the ICANN Board to the ICG and CCWG-Accountability
7 September 2015
Original posting: https://www.icann.org/news/blog/upcoming-comments-from-the-icann-board-to-the-icg-and-ccwg-accountability
This is a very important week as we work towards the end of phase one of the IANA Stewardship Transition. With both the ICG and CCWG-Accountability public comments coming to a close, the ICANN Board plans to submit comments into each process.
Firstly, the Board will submit comments on the ICG IANA Stewardship Transition Proposal. We are very appreciative of all the hard work done by the ICG members and the three operational communities to produce the ICG proposal. The main focus of our comments will be on the implementation of the proposals by ICANN as the current IANA Functions Operator.
Secondly, as discussed extensively over the past week, the ICANN Board will submit comments on the CCWG-Accountability 2nd Draft Proposal on Enhancing ICANN Accountability. These inputs will include:
- Comments on the mission and core values; and
- Suggested enhancements of elements of the draft report; and
- A matrix of the key elements proposed by the CCWG-Accountability highlighting the elements of alignment between the Board and the CCWG-Accountability as well as the elements where the Board has suggested enhancements.
We thank the community for their consideration of our comments and continued trust in the multistakeholder process that has got us this far. The continued back and forth of ideas and opinions is how we will together build the strongest proposal for the IANA Stewardship Transition, and we look forward to the next steps in the process and encourage all interested parties to submit their comments before the deadline.
Working Together Through The Last Mile
3 September 2015
Original posting: https://www.icann.org/news/blog/working-together-through-the-last-mile
I'd like to thank everyone who has participated in both the CCWG briefing to the ICANN Board, and the CCWG and ICANN Board dialogue. All of our dialogues over the past months have been illuminating, challenging and in my opinion, an important and true testament to the multistakeholder model as we work toward the IANA Stewardship Transition.
We support the important improvements for ICANN's accountability contained in the CCWG-Accountability's 2nd Draft Proposal. We endorse the goal of enforceability of these accountability mechanisms, and we believe that it is possible to implement the key elements of the proposal. We want to work together to achieve the elements of the proposal within the community's timeline while meeting the NTIA requirements.
As we enter the final days of the Public Comment period, the Board wants to be completely clear on our position. We are in agreement on key concepts set forward in the CCWG's proposal, for example:
- Fundamental bylaws.
- Specific requirements for empowering the community into the bylaws adoption process.
- IRP enhancements.
- Board and director removal.
- ICANN's mission and core values.
- Strengthening requirements for empowering the community in the budget, operational and strategic planning process.
- The incorporation of the Affirmation of Commitments Reviews into ICANN bylaws.
- Community ability to enforce the accountability mechanisms in the bylaws.
We have suggestions on how these could be operationalized. With regards to the mechanisms for community enforceability, where the current proposal still warrants much detail that may not be achievable we have a suggestion on how to deliver on it in a stable way, as increased enforceability must not open up questions of, for example, capture or diminishing of checks and balances.
Let's work together on operationalizing the above principles on which we agree. Once again, we are committed to providing more detail on how these ideas can be operationalized in a way that they can be implemented within the community identified time frame for the transition, as well as have sufficient tested grounds to not result in unintended consequences.
During last night's discussion we shared this feedback. It was a lot of information to digest in a call (notes around opening remarks, notes around 10 points), and we appreciate everyone giving our advice consideration. We are committed to submitting our comments into the Public Comment process in the next few days, and we look forward to the working with the community on further details.
It is critical that we work together to build enhanced accountability for ICANN and continue to refine and flesh out details of the impressive work already done by the community and complete the IANA Stewardship Transition.
CCWG-Accountability Draft Proposal Delivery Framework
2 September 2015
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2015-September/005161.html
- Develop Fundamental Bylaws and Process for Modification
- Bylaws areas:
- ICANN's Mission and Core Values.
- Reviews imported from the Affirmation of Commitments, including modifications with community consensus.
- The requirements for having community input and consultation on development of ICANN Budget, Strategic Plans, Operating Plans and Standard Bylaws. This includes the IANA Functions Budget as well.
- Commitment to fund IANA Functions housed within ICANN.
- IANA Functions Reviews called for within the CWG Report, with commitment to implement recommendations from those reviews.
- Change process - When Board proposes changes to Fundamental Bylaws (including amendments, additions or deletions):
- Incorporate into the Bylaws a requirement for community comment and input.
- Empower the community to support such a change through a demonstration of consensus in the community. Consensus in this situation is demonstrated through meeting the specified threshold of numbers of SOs or ACs needed to support the proposed change.
- Once there is community consensus to support the change, the change is effective upon 3/4 of the Board voting in favour of the change.
- Bylaws areas:
- IRP Enhancements
- Roll back modification of standard of review that was in place before 2013.
- Commitment that revised standard of review, standing panel and procedural improvements will be part of next phase of work on IRP enhancements.
- Expand Reconsideration Process and Define Clear Escalation Path For Accountability
- Expand scope of reconsideration process to define as an initial step in seeking challenge against Board or staff action. Expansion could include:
- Allowance of Reconsideration Process to be used in allegations that the Board acted in violation of the Articles of Incorporation or Bylaws.
- Increase from current process-driven bases to areas of more substantive concern, such as unfairness of a decision or inconsistency of logic.
- Following Reconsideration Process, use IRP and build escalation through accountability mechanisms, resulting in development of full appeals process.
- Expand scope of reconsideration process to define as an initial step in seeking challenge against Board or staff action. Expansion could include:
- Establish new Multistakeholder Enforcement Mechanism (MEM):
- Process for community to bring challenges against Board action that is alleged to be inconsistent with specified fundamental Bylaws.
- Binding arbitration process that is enforceable in California Courts
- ICANN funds MEM arbitrations.
- The MEM shall not be available for challenges based upon the adoption of ICANN's annual budget or annual operating plan.
- Community Involvement in Development of Standard Bylaws Changes, Budgets, Operating Plans and Strategic Plans
- Incorporate into the Bylaws a requirement for community comment and input on each of these areas.
- Empower the community to raise timely consensus-based issues or concerns on a proposed Board action ("Community Concerns"). Consensus in this situation is demonstrated through meeting the specified threshold of numbers of SOs or ACs needed to support the raising of an issue or concern.
- ICANN commits to working with the community to resolve areas of Community Concerns, through a consultation process.
- Provide a consultation process (borrowing from the GAC/Board consultation requirement), if the Board intends to take action that is inconsistent with the Community Concerns, to work to resolve the inconsistencies where possible, or if not possible, then a 2/3 Board threshold needed for Board to act against the general Community Concerns.
- Board Removal/Recall
- Institute pre-service letters to require the resignation of each director upon the occurrence of specific events:
- Serious violation of governance standard, including statutory causes for removal (such as fraud).
- Refusal to abide by the processes set forth to enable new community empowerment areas.
- Failure to abide by outcome of Multistakeholder Enforcement Mechanism (defined in #5 below).
- Process for invoking the resignation requirement. Any removal of a director is a very serious action, which must include a special community rationale and justification for removal of any individual directors and a special process for removals that would impact a significant number of voting directors. The process should allow for Board members to have an opportunity to defend against allegations that could support removal, and also include the potential for the imposition of sanctions less severe than removal.
- Institute pre-service letters to require the resignation of each director upon the occurrence of specific events:
- Incorporate Affirmation of Commitments Reviews into Bylaws
- Consider proper edits to WHOIS review.
- Commitment to work with community on guidelines for reviews:
- Review team size and composition.
- Budget.
- Access to experts.
- Access to ICANN documentation.
- Expectations on process for adoption and implementation of reviews.
- Optimization and standardization of review team processes.
- Implement All ICG Contingencies
- Confirm CSC is included in enhancements.
- Work with ccNSO and GNSO to confirm ability to address performance-related issues is appropriately documented.
- Institutionalize in Bylaws the current practice of Board/GAC consultation requirement used only over consensus advice
- Identify and commit to a process for defining continuous improvement work how the Board will consider those recommendations
- Bylaws requirement that continuous improvement ideas must be supported by a high threshold of the community and to uphold the following criteria consistent with the lines of the NTIA Criteria, which are:
- Support and enhance the multistakeholder model;
- Maintain the security, stability, and resiliency of the Internet DNS;
- Meet the needs and expectation of the global customers and partners of the IANA services;
- Maintain the openness of the Internet; and
- Not result in ICANN becoming a government-led or an inter-governmental organization.
- Utilize existing mechanisms as home for some of the other identified areas of continuous improvement, including ATRT3.
- Bylaws requirement that continuous improvement ideas must be supported by a high threshold of the community and to uphold the following criteria consistent with the lines of the NTIA Criteria, which are:
Opening Remarks from ICANN Board/CCWG-Accountability Dialogue
2 September 2015
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2015-September/005160.html
- We endorse the goal of enforceability, and we believe that it is possible to implement it along with the key elements of the proposal, without a wholesale change of ICANN's model of governance. We stand ready to work with you on an implementation approach that achieves your goals without causing instability or unintended consequences.
- The proposal contains important improvements for ICANN's accountability. In principle, we support enhancements to ICANN's accountability, as reflected in the four building blocks of an empowered community, the ICANN board, principles, and independent appeals mechanisms. We also understand that the drive for a sole membership model is the community requirement of enforcement. We are committed to continuing to participate in the community process to develop a consensus proposal that meets the community's requirements by the time of the ICANN meeting in Dublin.
- We have concerns on how to implement the current 2nd draft proposal as it stands, without causing unintended consequences of instability and institutional ineffectiveness, increasing the potential for capture, changing the stable/accepted advisory role of governments at ICANN, or crossing perceived political lines. We also refer you to concerns shared by Board members both in Buenos Aires and then again in writing on 7 July 2015, regarding unintended consequences that could weaken ICANN's governance model; impact ICANN's financial stability, causing possible budget paralysis among other potential ramifications; and impact ICANN's Board by turning it into, for example, a representative body or parliament.
- We want to work together to achieve the elements of your proposal - including enforceability - within the community's timeline and without causing those unintended consequences. We are not suggesting a new proposal, but we have some initial ideas about how to deliver on this.
- In addition, we suggest building on processes for addressing on-going improvement work so that ICANN remains in a continuous improvement cycle. We believe this process for continuous improvement can be built using the same NTIA criteria that have been the foundation of this transition.
The Latest Update on the Board's Review of the CCWG Proposal
28 August 2015
Original posting: https://www.icann.org/news/blog/the-latest-update-on-the-board-s-review-of-the-ccwg-proposal
As reported Wednesday, the Board is engaged in full review of the CCWG-Accountability proposal. In line with our commitment to be open and transparent about our process, we are using this space to update the community on our next steps.
A subset of the ICANN Board and staff members finished a productive series of meetings this week focused on the CCWG proposal. We shared Wednesday that as part of this meeting, the group held a call with the CCWG Chairs, and met with several advisors. Additionally, we met with Larry Strickling, Assistant Secretary for Communications and Information and NTIA Administrator. The Board also held an informational call today. We would like to thank everyone for their time and valuable contributions to our discussion.
Also, as reported earlier this week, we have received an impact analysis of the proposal from our external counsel Jones Day. The impact analysis has been posted to the Public Comment forum [PDF, 539 KB].
On Monday 31 August, the CCWG will hold a 90-minute call at 22:00 UTC to brief the Board on its proposal, and also provide an opportunity for discussion. Details of the call will be posted to the CCWG wiki so that anyone in the community may participate.
On Wednesday 2 September, the Board and the CCWG will hold a call for the Board to share its feedback on the proposal. This call will take place at 22:00 UTC and can be streamed live through Adobe Connect. There will also be an opportunity for a follow up call if needed.
After those conversations with the CCWG, the Board will post its comments in the Public Comment forum.
We are committed to working productively and constructively to achieve a successful IANA Stewardship transition and an ICANN with enhanced accountability. We remain appreciative and supportive of the CCWG's valuable work.
ICANN Board Submission of Jones Day Impact Analysis
27 August 2015
Original posting: http://forum.icann.org/lists/comments-ccwg-accountability-03aug15/msg00007.html
The ICANN Board is sharing an impact assessment it received from Jones Day on the CCWG-Accountability's Second Draft Proposal. This assessment was recently received by ICANN. In the spirit of transparency, we are submitting this in the CCWG's public comment forum so that the ICANN community can see the inputs that the Board is receiving as it is analyzing the CCWG proposal.
Jones Day, ICANN's external counsel, was asked to review the CCWG-Accountability's proposal and provide advice to ICANN on the impacts of the proposal. This work included identification of areas where the proposal had sufficient detail to proceed to implementation as well as identification of areas where additional detail is needed prior to being able to advise ICANN on its ability to ultimately adopt the proposal. For the areas where additional detail was needed, Jones Day was asked to identify potential alternatives to the implementation that could still achieve the bulk of what the CCWG was attempting to accomplish. In developing the impact analysis, Jones Day was also asked to explain the CCWG proposal as they understood it; if there are areas where the explanation does not match the CCWG's intent, the Board and CCWG should engage in discussions to reach a common understanding.
This impact assessment is advice to the Board. The Board is taking this advice, along with its discussions with the CCWG-Accountability, advisors and staff, as inputs into developing detailed comments on the Proposal. There may be areas where the Board comments will not reflect the Jones Day advice.
We are committed to continuing to participate in the community process to develop a consensus proposal that meets the community's requirements.
Full Jones Day Analysis located here: http://forum.icann.org/lists/comments-ccwg-accountability-03aug15/pdf5bBqNGP8Fj.pdf [PDF, 539 KB].
Updating our Community on our Review of the CCWG-Accountability Proposal
26 August 2015
Original posting: https://www.icann.org/news/blog/updating-our-community-on-our-review-of-the-ccwg-accountability-proposal
The Board is deeply engaged in reviewing the CCWG-Accountability proposal and has actively participated in the process. Consistent with our commitment to transparency, we would like to share with the Community the steps in our review process.
Last week, the ICANN Board submitted a preliminary set of comments to the CCWG-Accountability Public Comment forum. The Board remains committed to engaging and working with the CCWG on solutions to address concerns raised in its preliminary set of comments.
A subset of ICANN Board Members and Staff Members have been meeting in Washington, DC on Tuesday and Wednesday this week to further consider the CCWG proposal and commence a review of an impact analysis from ICANN's external counsel. As part of this meeting, the group held a call together with the CCWG Chairs. For full transparency and to clarify the basis for the review points and comments, ICANN will share the impact analysis and publish it in the CCWG Public Comment forum. The Board welcomes feedback from the CCWG on the impact analysis as it finalizes its responses to the CCWG proposal in the Public Comment forum.
Next week, consistent with the CCWG request, the Board will have an open teleconference with the CCWG to help inform the Board's development of its comments to be submitted into the Public Comment forum before the close of the comment period on 12 September. Call details will be announced so that anyone in the community may participate.
Finally, in light of the importance of these discussions, we propose that the CCWG-Accountability hold a public meeting in Los Angeles in late September to continue the dialogue with the Board on the CCWG proposal.
As part of the ICANN community, we will continue to work constructively to help the CCWG finalize the proposal to achieve a successful IANA Stewardship transition and an ICANN with enhanced accountability. We remain appreciative of the CCWG's valuable work.
ICANN Response to Proposed RIRs/ICANN SLA
26 August 2015
Original posting: https://www.nro.net/pipermail/ianaxfer/2015-August/000647.html
ICANN agrees with the Regional Internet Registries' CRISP team that a Service Level Agreement (SLA) between the parties complements the existing Memorandum of Understanding (2004 MOU) and Exchange of Letters between ICANN and the NRO (2007), and sets a strong framework to better serve the global Internet community. The Service Level Agreement is anticipated to supplement the MOU and Exchange of Letters by fleshing out the services ICANN is expected to deliver as well as the levels of performance expected for those services.
Most of the requirements in the proposed SLA document describe pre-existing requirements from the NTIA's Statement of Work (SOW) with ICANN for the performance of the IANA functions as bound together today. ICANN believes that a thorough and detailed operational review will result in an SLA agreement that is tailored more to the needs of the RIRs and ICANN. This review would include identification of some of the commitments that ICANN currently undertakes in the NTIA agreement that do not necessarily impact delivery of an excellent service to the numbering community. ICANN fully supports the open and transparent process that the RIR community has followed up to now and anticipates that the process of arriving at a final SLA will require review and acceptance by the number community. ICANN proposes that the process between the RIRs and ICANN includes an operational review between RIR and ICANN staff directly involved in the IANA functions-related operations through a series of meetings. The proceedings of these meetings will be open to community observers and recorded for transparency purpose. Remote participation facilities will be made available to the wider community to join.
If agreeable to the RIRs, we are ready to plan an initial face-to-face meeting at the upcoming ICANN meeting in Dublin. At this meeting, some areas worthy of attention that we would like to cover include but are not limited to: (1) agreement on relevance of all portions of the NTIA contractual clauses referenced in the SLA document and the applicability to RIR services; and (2) clarification on expectations of ownership of systems and tools used in the performance of the numbering - related functions.
We propose that our organizations nominate a small team of operational staff who will have an initial meeting in Dublin. This initial meeting would begin the process of discussing the operational details of a SLA with the goal of defining the operational services and performance expectations of those services. After the RIR and ICANN operational teams have completed the review process, our respective legal teams can review the agreement to ensure the operational expectations are well covered, including considerations of how the SLAs impact the design of the current RIR/ICANN relationship documentation.
ICANN is fully and enthusiastically supportive of and in agreement with the RIR proposal expressed in the NRO Chairman's email to ICANN's Chairman of the Board to engage in a process to formalize the services, tasks, and commitments necessary to fulfill the IANA numbering function.
We look forward to full cooperation with the Internet numbering community starting with the initial meeting in Dublin to arrive at an effective, efficient and sustainable agreement to cement our long lasting partnership.
Preliminary ICANN Board Comments on the CCWG-Accountability Second Draft Proposal for Public Comment
20 August 2015
Original posting: http://forum.icann.org/lists/comments-ccwg-accountability-03aug15/msg00006.html
The ICANN Board thanks the CCWG Accountability for all of its work leading to the second draft proposal of mechanisms to enhance ICANN accountability in light of the changing historical relationship with the US Government.
The Board has been active and engaged in the recent CCWG work, including many members attending the CCWG's face-to-face meeting in Paris, and has witnessed first hand the amount of thought and dedication that has gone into the CCWG's work since last year.
The Board reconfirms its support of this process and its commitment to finding a final CCWG proposal that is acceptable to the whole community, including the Board and NTIA. We join with you in embracing the important goal of community empowerment in the ICANN multistakeholder model.
We believe that a solution that ensures ICANN's ongoing accountability to all stakeholders is both desirable and possible. It is desirable to seize this historic opportunity to build on the successful ICANN model of multistakeholder governance and commitment to the public interest that has developed since its founding. It is possible given the hard work of the community and the shared commitment of all stakeholders to improving the transparency and accountability of ICANN. The Board believes that the four building blocks set forth by the CCWG provide a strong foundation on which to build, and look forward to working together as the details are developed.
The ICANN Board is committed to the CCWG's accountability enhancement goals and believes that much of what is contained in the proposal is encouraging and workable. We recognize the importance of affording the ICANN community the ability to assure that:
- the Strategic Plans of ICANN are within ICANN's mission;
- budgets support the mission; and
- the Board does not have unilateral ability to change the Bylaws, particularly those parts of the Bylaws that are fundamental to maintaining the Board's accountability to the community.
The Board understands the community's need to have a tool to ensure that the Board (as a whole and as individuals) does not act outside the scope of ICANN's mission. We also agree that the Independent Review Process needs to be refined. The Board agrees that a key part of successfully concluding the transition is to deliver these accountability enhancements. Because these must be achieved without destabilizing or weakening the delicate balance of the stakeholders in the ICANN multistakeholder model, the Board is carefully reviewing the proposals to ensure we believe that they can maintain this balance and that there is a safe, stable way to implement the changes. ICANN is committed to work with the CCWG on this plan moving forward.
As part of our review, the Board is doing the following:
- First, we are seeking ICANN's external counsel's inputs on the proposal. The Board intends to share that input with the CCWG and post in the Public Comment forum as soon as possible, so that there is a common baseline for further discussion.
- Second, ICANN is reaching out to independent third-party experts on governance to obtain an analysis of the governance impacts of the proposal, including considerations of how the proposal may impact the balance of the stakeholders in the multistakeholder model within ICANN today. The Board will also share that analysis with the CCWG as soon as it is received.
- Finally, and using the briefing materials identified above, the Board will continue to work on its own set of more comprehensive comments and suggestions to the proposal, and will submit that into the Public Comment forum prior to the close.
Initial Impressions of the CCWG's Proposal
While the detailed review work is still forthcoming, a preliminary review of the Proposal indicates that there are still some areas where key details will need to be finalized before the transition of the stewardship from NTIA can occur. Below are some examples of areas that need to be finalized or improved. Our fiduciary duty as Board members requires us to understand the operational impacts of the recommendations that the community will be asking the Board to accept in the near future, so the Board will work to identify the open areas that need to be finalized. The earlier questions provided by the Board to the CCWG were an attempt to point out areas where additional information or considerations would be helpful in supporting the proposal. While the shift to the sole member model has removed some of the questions about individual parts of the ICANN community being able to exercise statutory powers, the Board's intent was and continues to be that the questions serve as guidance to the CCWG in considering whether sufficient detail is in place within the proposal.
Everyone involved in this process is strongly committed to protecting our unique, bottom-up, multistakeholder model – where all participants have confidence in the multi-equal, stable and balanced nature of the process. Indeed both the proposal and the NTIA criteria stress that must be preserved.
NTIA had always intended to transition its IANA stewardship role to ICANN and the multistakeholder community. The March 2014 announcement from NTIA that the US Government would start the process of transitioning that role came only after ICANN's 16 years of operation demonstrated that ICANN was mature enough for the transition to occur. Assistant Secretary and NTIA Administrator Strickling reflected then and later in subsequent speeches and blogs that ICANN's demonstration that its model was mature and effective is what made NTIA confident that the timing was right.
ICANN Statement Regarding IANA Intellectual Property Rights (IPR)
15 August 2015
Original posting: https://www.icann.org/news/announcement-2015-08-15-en
ICANN supports the IANA Stewardship Transition Group (ICG) proposal and the underlying proposals from the Community Working Group (CWG), the Consolidated RIR IANA Stewardship Proposal (CRISP) team and the Planning for the IANA/NTIA Transition (IANAPLAN) working group.
The ICANN Board is focused on how to implement the Intellectual Property Rights (IPR) component of the proposal. The Board believes that for stability and pragmatic operational reasons, the IANA Functions Operator must have operational control over the IANA.ORG domain.
During the transition, ICANN is prepared to transfer full ownership of the IANA-related trademarks to a neutral third party mutually agreed among the operational communities with the understanding that ICANN, as the current IANA Functions Operator, will be granted license to those trademarks and ICANN will maintain operational control of the IANA.ORG domain for as long as ICANN remains the IANA Functions Operator.
If the transfer during the transition affects the timeline, we advise delay until after the transition. In that event ICANN is ready to hold the IPR as interim measure but commits to transfer it within 120 days after the neutral third party is identified by the operational communities.
We believe this is neutral and in the public interest. We look forward to hearing from anyone in the community.
ICANN Board Liaison to ICG Comments on iana.org
2 July 2015
Original posting: http://mm.ianacg.org/pipermail/internal-cg_ianacg.org/2015-July/000814.html
"ICANN currently holds IANA.ORG <http://iana.org/> and the IANA trademark for the benefit of the community and in support of ICANN's performance of the IANA functions. The board recognizes that the community is considering different models for the maintenance of the iana.org <http://iana.org/> domain name and the related trademarks.
The board wishes to reassure the community that in the event any of the IANA functions are transferred away from ICANN, appropriate rights to use the intellectual property associated with the IANA functions will be granted without delay to the new operator or to an entity the operational communities unanimously designate.
It is important that any new model should maintain the stability of the technical operations of the IANA functions and continued ability to use the intellectual property associated with IANA for all of the operational communities."
ICANN Impact Analysis/Questions: Community Working Group (CCWG) Accountability Initial Draft
18 June 2015
Original posting: http://mm.icann.org/pipermail/accountability-cross-community/2015-June/003437.html
The following questions are intended to help the CCWG fully explore the implications of the proposed recommendations on how the ICANN community will operate in future.
Questions are provided for each of the major areas of the CCWG-‐Accountability Recommendations. The questions are divided into: 1. issues that seem to be essential to understand how the proposals meet the NTIA criteria; 2. areas where additional information would be helpful, and 3. questions that address more minute details that may be more appropriate for implementation as opposed to the recommendation design.
CCWG Proposal: SO/AC Membership Model |
(Objective – Enhance ICANN accountability through empowerment of the Community by making SOs/ACs statutory members of ICANN) |
|
Meeting the NTIA Criteria:
Areas where additional information is needed: Questions that provide implementation level details: |
CCWG Proposal: Community Right to Cause Reconsideration of or Reject Board Approved Budgets and Strategic/Operating Plans |
(Objective – Enhance ICANN accountability through empowerment of the Community by giving Members the ability to reject ICANN's Budget and Strategic/Operating Plans) |
|
Meeting the NTIA Criteria:
Areas where more information is needed: |
CCWG Proposal: Community Right to Reject Changes to "Standard" Bylaws and Approve Changes to "Fundamental" Bylaws |
Objective – Enhance ICANN accountability through empowerment of the Community by granting members with specific right as it relates to the amending "Standard" and "Fundamental" Bylaws |
|
Areas where further information is needed:
|
CCWG Proposal: Community Right to Remove Individual ICANN Board Members |
Objective – Enhance ICANN accountability through empowerment of the community by granting members the right to remove individual directors) |
|
Areas where further information is needed:
|
CCWG Proposal: Community Right to Remove Entire ICANN Board |
Objective – Enhance ICANN accountability through empowerment of the community by granting members the right to remove the entire ICANN board) |
|
Meeting the NTIA Criteria:
|
CCWG Proposal: Independent Review Process Enhancements |
Objective – Enhance ICANN accountability through enhancements to the Independent Review Process |
|
Meeting the NTIA criteria:
Additional information needed: |
Comments on the Draft RIR Service Level Agreement for the IANA Numbering Services
14 June 2015
Original posting: https://www.nro.net/pipermail/ianaxfer/2015-June/000588.html
Thank you for the opportunity to respond to the SLAs as put out for public comment by the RIR community. We recognize the significant commitment of effort by the Numbers community in producing both the response to the ICG RFP and this document, and look forward to further progress.
Please note that these comments are not a legal review of the proposed SLA by ICANN and that such review will only be possible when ICANN and the number community enter in formal negotiation on the final version of the contract. The comments below seek to highlight some questions with regards to the approach of the SLA. We are happy to expand and discuss further with the community and continue to comment as the SLA terms are further developed.
With regards to the draft provided, we have some observations that lead to the questions below:
- Has it been considered that there may be an incompatibility between clause 10.2 of the SLA (termination at will) and the escalation mechanisms elsewhere in the document? In this context, has the 12 May 2015 question posed by Vint Cerf to both the IETF/IAB and the RIRs/NRO, which asked "Is there a capability within the NRO or the collective RIRs to perform the functions now provided by the IANA function within ICANN? Could this capability serve as a back up in the event that ICANN's IANA service to the RIRs is not meeting performance requirements?" been considered as part of an appropriate escalation mechanism?
- Have the requirements as set out by NTIA, specifically the requirement that any model not be government run, been considered?
- We have noted that the document has taken an approach of identifying acceptable levels of service, rather than identifying the services ICANN, as the IANA functions provider, must implement on behalf of the numbering community. Will it be possible for the final SLA to clearly list they key services expected from ICANN, as the IANA functions operator?
- Can the SLA include mutual accountability mechanisms for both ICANN and the number community, to ensure ongoing accountability, openness and transparency, to be reflected in the SLAs for both parties?
- The services provided by the IANA functions are part of managing a shared global resource and as such, means there are shared responsibilities. Could the SLA provide for a framework for such shared responsibilities? Can the SLA list key obligations or responsibilities of the RIRs in managing these resources at the regional level so as to ensure the overall stability and accuracy of the global number identifiers registry?
To provide clarity in defining our working relation post transition, we would like to suggest to separate the SLA that governs the Services provided through the IANA function contract from a new document to be drafted (MoU, AoC) that defines the framework for cooperation and mutual commitment to accountability and some binding principles. We believe that loading the SLA with everything may be counterproductive in the long term.
ICANN Board Input on Implementation Timeline to ICG
12 June 2015
Original posting: http://mm.ianacg.org/pipermail/internal-cg_ianacg.org/2015-June/000665.html
Dear Alissa,
Thank you for your 1 June 2015 note regarding NTIA's communication to the ICG and the CCWG-Accountability on the status of the transition planning, and the associated time-frames for finalizing the proposal and the implementation.
The Board looks forward to receiving the proposals upon completion by the community. As noted before, upon receipt of the proposals, we will transmit them to NTIA, accompanied by any additional comments we may have already reflected in our input to the community
In this regard, as to the status of the proposals, we're pleased to see the operational communities hard at work in reaching conclusions, and look forward to the submission of the naming community proposal to the ICG. With regards to the accountability process, we welcome the progress made and look forward to the conclusion of the recommendations on Workstream 1.
As to the steps leading to the final execution of the proposals and recommendations, we see several phases, that can be outlined at a high level as:
- Preparation of the proposal and forwarding to NTIA;
- The period in which NTIA and the US Government review the proposal, including any work ICANN needs to undertake during that time-frame; > ·
- Path leading to implementation upon sign-off by the US Government and the ICANN Board.
- Final implementation and operationalization
With regards to the path leading to implementation, the Board believes that it will be necessary for ICANN to follow its normal processes for dealing with reviews. This will include the normal process for bylaws changes, where the proposed new text will be published for public comment before Board approval, and the normal process of taking public comment for important implementation options and details.
With regards to timelines, we expect the implementation time-frames applicable for each of the operational communities to vary. For example, we would expect the IETF and RIR parts of the ICG proposal, as currently prepared, to be fairly straight-forward and we'd estimate each requires a matter of weeks to finalize. The naming community proposal will take longer - we'd estimate several months - given the new elements that need to be implemented, including, for example, bylaws changes and structural changes necessary to form the PTI. Another example is that time will be required for the community to select representation to, the CSC. To the extent any parts of the ICG proposal rely on the Accountability process recommendations, implementation time-lines will need to take those into consideration.
With regards to the Accountability process, it's premature to determine how long implementation will take. Experiences from the ATRT and organizational review processes though indicate that it could take at least two ICANN meeting cycles. The timeline will be strongly impacted by the implementation mechanisms needed for the proposed accountability improvements.
To the extent possible, we will strive to do advance planning to prepare for putting elements into place with regards to the respective proposals, to then require as short a time-frame as possible to implement and operationalize any final parts necessary for the conclusion of the contract. This includes, for example, any pre-work with respect to identifying the bylaws changes.
In working with the community, and in reviewing the community timelines, we are preparing for receipt of the ICG proposal around the ICANN 54 meeting, together with the CCWG Workstream 1 proposal. We anticipate that there will then be a time frame established for the NTIA's review, during which we can begin implementation work. The timeline of implementation will be impacted most directly by, for example, complexities within the proposals, the need for the community to utilize ICANN's meetings for any elements relating to community mechanisms, or proposals that require additional implementation work to complete.
Steve
ICANN Board Comments on the CCWG-Accountability Initial Draft Proposal for Public Comment
3 June 2015
Original posting: http://forum.icann.org/lists/comments-ccwg-accountability-draft-proposal-04may15/msg00049.html
The ICANN Board thanks the CCWG-Accountability for all of its work leading to the first draft proposal of mechanisms to enhance ICANN accountability in light of the changing historical relationship with the US Government. As the CCWG-Accountability prepares its proposal, the Board has some comments, observations and questions for the CCWG to consider. We provide these below, and look forward to continued discussions, including at the upcoming ICANN 53 meeting.
Our comments below are focused on the mechanisms discussed in the proposal falling under Work Stream 1.
As discussed at ICANN52 in Singapore, the Board reiterates that the main areas of proposed enhancements are items that the Board supports. We understand and appreciate how important these changes are to the CCWG-Accountability, and agree that there is a path forward to achieve the community powers and enhancements identified in the CCWG-Accountability's first report. We recognize the importance of affording the ICANN community a voice in assuring that the Strategic Plans of ICANN are within ICANN's mission, that budgets support the mission, and that the Board does not have unilateral ability to change the Bylaws, particularly those parts of the Bylaws that are fundamental to maintaining the Board's accountability to the community. We understand the community's need to have a tool to deter the Board (as a whole or as individuals) from neglecting ICANN's mission, and how a powerful tool may allow for appropriate action to deter such behavior. We agree that the Independent Review Process needs to be refined; with the standard better defined to meet the needs of the community, and that it is important to have binding decisions arising out of that process, as appropriate. As we noted in Singapore, we are far more closely aligned with the CCWG-Accountability than many in the community might realize.
Starting from the baseline that we are supportive of the CCWG-Accountability's main goals, we then have to turn to considerations of implementation – how do we make sure that the goals are implemented in ways that do not pose undue risks to how the ICANN community interacts within the ICANN multistakeholder model?
One of the analyses that we do not see within the report is a something akin to a regulatory impact analysis, where the costs, benefits and alternatives to proposals are weighed to assure that the design of the solution for each issue is the most efficient, least burdensome on the community, and most cost-effective solution. This seems a separate exercise from the stress test work that is reflected in the report. That stress test, or contingency planning, work builds from the identification of stressors or situations that ICANN may face, and then considers how the 2 proposed solutions assist ICANN in being more accountable when those situations arise, however unlikely. This is valuable work in considering that the CCWG-Accountability is working towards the crucial issues. What seems to be the necessary next step, however, is considering whether the mechanisms that are proposed as solutions are themselves capable of withstanding contingencies and stressors. In this regard, the Board presumes there will be an impact analysis. It is currently working on a series of questions to assist in performing that impact analysis.
The membership model that is described within the CCWG-Accountability report is one of those main areas for which impact testing seems to be needed. One of the foundations of the CCWG-Accountability report is that a move to a membership model is a means to achieving the enhancements identified. The membership model is noted as providing a "viable" solution, with viable meaning "enforceable through a judicial process." (Annex A to 23 April 2015 Counsel memo.) Recognizing that there is continued debate surrounding this enforceability issue on the CCWG-Accountability mailing list, the concept of membership and enforceability seems to raise some questions that should be considered prior to accepting a specific model, including analysis of what risks and liabilities are being introduced into the system as a whole. For example, while clearer community paths for impacting Board decisions may result in few situations where the community agrees that it is necessary to go to a California court to enforce a right against ICANN, there seems to be other questions about enforceability and impacts have not yet been considered. Such as:
- What opportunities and rights of action are we opening up under law for individual members to bring against ICANN that cannot be constrained by the Bylaws?
- What rights under law do members have to bring actions against other members, and what impact could that have on the multistakeholder model? Does this create opportunities for capture of ICANN or ICANN processes that are not an issue today?
- Are all parts of the ICANN community comfortable with the role that California courts will assume in enforceability of accountability reforms through the membership model?
- If any SO/AC does not want to be a "member," how does this affect the proposed SO/AC Membership Model? Would it minimize that SO/AC's participation in the ICANN process if other SOs/ACs have the proposed powers and rights that the "missing" SO/AC does not?
We do have a concern that the extent of the governance changes that could be required through the CCWG-Accountability creates the possibility for too much change to be introduced into the ICANN system at once. As one of the participants in the recent Board workshop panel on the IANA Stewardship Transition cautioned, sound engineering practices are based in incremental change and following with additional reforms as needed, as opposed to changing everything at once. When you 3 change too much at once, and there is later an issue, it's very hard to figure out what part of the change caused the issue. A shift to a membership model, which may introduce a large number of changes into the whole governance model, is indeed an area where there is potential for unintended consequences. We believe that it's important to keep this principle in mind as impact analysis is performed.
We also support one of the advisors to the CCWG-Accountability, Jan Aart Scholte, in his continued reminder to make sure that the solutions and governance changes that are being introduced today include considerations of how the different parts of the ICANN community remain accountable to each other, and allow for those who are not affiliated with any of the current structures to have meaningful participation options in the future. We recommend that this be part of any impact analysis as well.
Aside from these high-level issues that we wish to bring to the forefront, we also have some specific questions on parts of the proposals:
- How will the principles proposed to enhance and improve the Mission and Core Values of ICANN be tested against the bylaws in their entirety? Given that modifying the Mission and Core Values was not part of the community discussion at the Singapore meeting, what is the CCWG-Accountability doing to highlight this change as part of the suite of recommendations? In asking this question, we are supportive of the idea that the mission statement and core values should be refined.
- Under the current governance model, advisory committees are responsible for the provision of advice to the ICANN community and Board on certain areas (GAC for public policy issues; SSAC on security and stability concerns; RSSAC on root server stability; and ALAC on the interests of individual internet users.) For the areas of the proposal that rely upon a community "vote" to determine whether action should be taken, how are those pieces of advice proposed to be taken into account? How does the CCWG intend to deal with a Board action based on advice received from an AC that does not choose to become a member? What are the processes that the community would use to reject a Board action based on advice from the GAC, if it elected to do so?
- What is the basis for proposing to distribute two votes each to the SSAC and RSSAC (collectively less than any other single group in the voting model) when the Bylaws do not reflect any weighting of import across ACs? How does the CCWG contemplate ensuring that the security, stability and resiliency of the DNS be considered and maintained if the vote of the RSSAC and SSAC play such a limited role?
- With regards to the inclusion of the Affirmation of Commitments reviews into the bylaws:
- Are there sufficient mechanisms in place to assure diversity of the review teams (geographic, gender, etc.)?
- What are the mechanisms to adjust the review processes as needed by the community?
- What are the mechanisms for ensuring costing and subsequent prioritization of recommendations, and determination if recommendations are feasible?
- What limitations on review team access to documents will be identified to address issues such as restricting access to employee records, trade secrets provided to ICANN by others, and assuring that competitors do not gain access to others' sensitive documentation that ICANN has within its files?
- To the extent that ICANN decisions are subject to review or approval through the ICANN "empowered community" model via members, how is that group of members subject to considerations of conflict of interest identification in its decision making?
- How will the impact of a community mechanism decision be assessed with regards to the broad global public to which ICANN is responsible? And will stakeholders not directly involved in ICANN have a voice?
- With regards to removing an individual board director, what is the threshold that triggers this? How will the process not be capturable? What will be the basis for removing a board member? Is it worth considering a threshold that requires more than one SO or AC to support the removal of a board member – thus ensuring that individual Board members are accountable to the whole community for their performance as a director, not just the SO or AC that originally selected them.
- With regards to removal of the entire board, what actions trigger this? What mechanisms will be in place to ensure continued stability and security of ICANN's mission and responsibilities, while a new Board is appointed?
- We recommend that language that is incorporated into the Bylaws on WHOIS be updated to reflect the potential for future modification and overhaul of the registration directory system, and not hardcode the legacy "WHOIS" requirements into the Bylaws.
- The proposed enhancements to the Independent Review Process (IRP) still appear to require further detail, including issues such as standing and remedies, as well as definitional work. What steps are in place to avoid overloading the seven-person IRP panel with frivolous or vexatious complaints? We anticipate further questions after more details are provided.
As we strive to look at the timeframes, clearly some of the proposals can be achieved more rapidly than others, building on existing mechanisms. New proposals, in 5 particular those changing the governance structure of the organization, require additional time for implementation and testing. Once the proposals become more concrete it would be useful for the CCWG to work with staff on a draft project plan for implementation.
ICANN Board Comments on 2nd Draft Proposal of the Cross Community Working Group to Develop an IANA Stewardship Transition Proposal on Naming Related Functions
20 May 2015
Original posting: http://forum.icann.org/lists/comments-cwg-stewardship-draft-proposal-22apr15/msg00038.html
The ICANN Board thanks the CWG for the intense work that led to this second draft. As the CWG-Stewardship prepares its proposal for the ICG, the Board has some comments, observations and questions that we believe need to be addressed or clarified prior to the proposal being finalized. In particular, we encourage the CWG to offer specific responses to the NTIA criteria.
The proposal incorporates many high-level concepts that seem to be workable as the board understands the proposal. As we understand:
- The PTI is currently proposed as a wholly-owned subsidiary to ICANN, performing its work under contract with ICANN, and limited to the discrete role of executing instructions from the users of the IANA functions on the implementation of the naming-related IANA functions and root zone management tasks.
- The PTI has no policy role, nor is it intended to in the future, and that while it will have control of the budget amounts ceded to it by ICANN for the performance of the naming-related IANA functions, the funding of the PTI will be provided by ICANN as part of the ICANN budgeting process.
- With the PTI being a lightweight structure, the accountability measures developed for use within ICANN apply; the PTI is not intended to be a replication of the ICANN model.
- CWG external counsel has advised that an internal, ICANN-appointed PTI Board makes the application of ICANN accountability mechanisms far more clear, and consider this an important element of the simplicity of design of an accountable PTI.
- The proposal indicates that the PTI and its board would be limited in scope to the minimum statutorily required responsibilities and powers, and execute instructions as given. The PTI would, of course, retain obligations of assuring that PTI performs to its requirements, including SLEs/SLAs, reviews, etc.
We understand that these are important facets of the CWG proposal, particularly to enable the ability to easily contract out the performance of the IANA Functions if that was determined to be needed in the future. On the basis of the above, we accept that this could be a workable model.
As the PTI idea continues to be formed, we think that it's important that concerns of security and stability in the performance of the IANA Functions in their entirety remain paramount. If there are choices between structures that leave the possibility for a new PTI to change its structure or assert more control in areas that are not 2 intended, as opposed to a structural design that does not provide the opportunity for that to happen, it is our position that the Internet is best served through a more predictable, fixed design. If there are issues that may arise with regards to any new structure, these should also be assessed in particular with regards to governance, accountability and implementation. It would also be helpful that the proposal further specify it is for the naming community.
The CWG Proposal also seems to have a path towards a lightweight PTI design that provides a clear bound for separability when/if needed, as well as for allowing the naming-related functions to be performed in accountable and transparent ways. We support these principles.
We also believe that the PTI should have the following additional principles at its core in order to support what is not only good for the naming-related community, but for the Internet:
- The PTI must have a clearly drawn framework that defines its remit.
- The PTI's role should be well defined.
- Maintaining the security and stability of the Internet DNS.
- No policy development nor interpretation role.
- Clear paths for coordination with other operating communities.
- Not undermine nor jeopardize ICANN's not-for-profit public benefit status.
- Simplified governance structure to allow easy alignment with current operations of the functions.
- The way in which the PTI exercises its role must be adequately and transparently documented.
- The PTI functions, processes and methods should be fully explained, and subject to peer/community review.
- The PTI should strive to adhere to organizing principles, such as:
- Advocacy and adherence to open, interoperable standards.
- Each party is responsible for what they contribute to the Internet.
- Decision-making should be open to all, and based on merit.
- Adherence to the Principle of Least Surprise.
- Stability at the core of the Internet.
- Permission-less innovation at the edge of the Internet.
In light of the above, in reviewing the proposal, the Board identified some areas where further information or clarification in the proposal would be useful. These include:
- In which areas does the CWG anticipate the PTI will be separate from ICANN, and where does the CWG see shared services as being allowable (ex: shared office space, HR, accounting, legal, payroll, etc.)? Additionally, we think it would be helpful to clarify the roles and responsibilities of the PTI Board vs. the ICANN Board. For example,
- From the proposal, we understand that the ICANN Board could approve an overall budget for the PTI, and the PTI would then manage within that budget, and return to the ICANN Board if more funding was needed. The PTI Board could have ability to enter into contracts within its budget, as needed. Clarifications around these topics and other guidance such as this could be helpful.
- What will be the nature of the relationship between the parent (ICANN) and its subsidiary (PTI) and will there be a clear line of reporting between the two entities? Will the duties of the PTI directors coincide with the strategy requirements of ICANN? Will PTI corporate governance be aligned with that of ICANN?
- If the PTI were to have, for example, separate legal staffing, what would happen if ICANN and PTI received conflicting legal advice on the implementation of an IANA-related policy? This is another area where clarity on the roles of ICANN Board and PTI Board could be helpful (ex: Would the ICANN Board be required to still perform the review of documentation to consider if proper procedures were followed in evaluating a ccTLD request for delegation or redelegation, and the PTI Board then be responsible for ensuring that the PTI initiates the requisite root zone change?)
With regards to the CWG proposal identifying a path for a new IANA Functions operator (if needed) to take over the operation of the functions under contract with ICANN, we agree this must occur, if needed, in a manner that is as seamless as possible, and in a way that preserves the security and stability of the Internet DNS. In this regard, the Board recommends that the CWG consider some principles for assigning a new IANA functions operator that pick up on the existing NTIA criteria (e.g., supports the multistakeholder model; not Government entity, etc.) as well as building in equal or stronger accountability mechanisms and protections against capture by any other group or entity in that assignment process. Once that new IFO is selected, is it anticipated ICANN hold a contract with the new IFO, through which the policy implementation and review requirements would be imposed on the new IFO?
Other Considerations
- When discussing the IANA Functions throughout the proposal, there is the potential that some of the references could be understood to refer to the IANA functions as a whole, and not just the naming/root zone management related functions. We recommend that the proposal would benefit from more clarity on this.
- Relationship with other operating communities: The CWG proposal has a lot of structure built in for the operation of the naming-related functions. Is it envisioned that PTI will operate the IANA functions as required by the Numbers and Protocol Parameters communities as well as the root zone management function? If so, how can some of this complexity be moderated to allow adequate space for other operational communities to participate, if they wish, while still keeping in line with the narrow technical scope of the IANA functions? Alternatively, is there any provision for their oversight of their IANA functions by separate arrangement with either ICANN or PTI? It seems there are a variety of configurations possible here, but any expectations or constraints on PTI regarding the other IANA functions should be clear in the proposal.
- We note that there are elements of the proposal that are new and may raise issues, including, for example, cost and efficiency, and what controls are in place for accountability and transparency. Are there any PTI-specific accountability mechanisms that need to be developed?
- What is the expected timeline for implementation of the proposal including testing against the NTIA criteria and accountability, and how will this impact the timing of the transition?
- With regards to separability, what steps for an escalation mechanism and separation ensure meeting the criteria set out by NTIA, and are there ways to manage that within the respective operational communities?
If legal separation is the preferred model, the Board acknowledges that there is ongoing discussion within the CWG as to the type of legal entity that should be formed. Any move to a separate entity must include considerations of the control mechanisms in place and the impacts of such a new legal entity. We encourage the CWG to identify of what would be the important aspects of that new entity. ICANN will need to separately research which organizational type is proper for ICANN to create, keeping in mind the CWG's identified criteria.
Development of SLEs/SLAs. The Board notes how important it is that there be appropriate and meaningful SLEs/SLAs for the naming functions customers of the IANA functions, as well as appropriate system design for the root zone updating functions. We encourage the CWG, and in particular the naming-related customers of the IANA functions, to work closely with ICANN staff to make sure that SLEs/SLAs and system design requirements are feasible, attainable and well understood.
ICANN 52 Board Statement on ICANN Sending IANA Stewardship Transition and Enhancing ICANN Accountability Proposals to NTIA
12 February 2015
Original posting: https://www.icann.org/news/announcement-3-2015-02-12-en
We have received several questions requesting clarification as to how ICANN will handle receipt of the proposal from the ICG and the Work Stream 1 proposal from the CCWG. We hope the following will be helpful.
NTIA is expecting coordinated proposals from both groups. They cannot act on just one. Further, they expect the ICG proposal will take into account the accountability mechanisms proposed by the CCWG. We are heartened by the close coordination between the groups, including liaisons from the ICG to the CCWG. ICANN is expecting to receive both proposals at roughly the same time. When ICANN receives these proposals, we will forward them promptly and without modification to NTIA. As we have previously stated, if we do submit the proposals with an accompanying communication of comments, they will be on points we had already shared with the community during the development of the proposals.
We therefore encourage the groups to continue coordinating closely to ensure ICANN receives the proposals together and is able to provide them to NTIA in a coordinated manner.
With respect to improvements in our accountability, we are definitely open to improvements.
ICANN Board Comments on Cross Community Working Group (CWG) Draft Transition Proposal for Naming Related Functions
22 December 2014
Original posting: http://forum.icann.org/lists/comments-cwg-naming-transition-01dec14/msg00032.html
The ICANN Board has been observing the development of the proposal within the Cross Community Working Group (CWG) on Naming Related Functions. We thank the CWG for the work that has gone into the development of its draft proposal and the opportunity to participate in the public dialogue.
We have been conscious of two guideposts during this process: to remain fairly silent so as not to attempt or seem to be attempting to inappropriately influence the process, and, at the same time to share our thinking with the community. The latter is particularly important since we will be called upon to do so when the final proposal emerges from the ICG. The final proposal will be forwarded to NTIA without modification but with our comments and recommendations, and NTIA has made it clear that consensus from the community includes the ICANN Board. We are in full support of the consultative process, and we have committed to share our views with the community in a timely fashion. More specifically, we appreciate that we should try to avoid introducing new issues after the ICG has coordinated the inputs it receives.
In this regard:
- Members of the Board are active participants in the work of the IETF, the Regional Internet Registries, the ccTLDs, ccNSO, and GNSO. We expect to be active within these stakeholder groups in providing input on the IANA Stewardship transition.
- We expect that any issues that the Board may identify will be raised early and dealt with during the process of formulating the final proposal.
The work in front of us is how to ensure the IANA function continues to be performed in a stable, secure, and transparent manner, how to make sure all policy related matters are handled outside of the IANA function operation, and how to enhance ICANN's accountability towards all stakeholders.
Accountability
We appreciate there are concerns about how to improve ICANN's accountability. This is the explicit purpose of the Cross Community Working Group (CCWG) on Enhancing ICANN Accountability. The work of the CCWG has started, and the output of Workstream 1 – that is Accountability in relation to ICANN's changing historical relationship with the US, is directly linked to the transition. As also stated by NTIA, "The two work streams on the IANA transition and enhanced accountability are directly linked and NTIA has repeatedly said that both issues must be addressed before any transition takes place.1 The topic of broader accountability, and sub-topics such as capture, or checks and balances, or oversight, or backstop, are important and need to be appropriately addressed in Workstream 1 of the Enhancing ICANN Accountability process. The ICANN Board agrees that there is inherently an important linkage between the evaluation of the transition proposals arising out of the IANA Stewardship Coordination Group and the outcomes of that Workstream 1, and we stress that we acknowledge that ICANN accountability is a fundamental concern of the community. We are not seeking to make light of it or dismiss it, but ask the CWG to distinguish the broader accountability questions from the issues of the performance of the IANA Functions and concerns about addressing the possibility of improper activity within the performance of the IANA Functions.
IANA functions
With respect to operation of the IANA functions, we believe that the creation of a separate 'contracting' entity not only poses risks when weighed against the NTIA Criteria, including potential future DNS security and stability risks, it also overreaches. The operationalization of multiple entities would raise questions about the accountability and transparency of each, as well as possible duplication of existing mechanisms and the imposition of cost and complexity on necessary processes. More to the point, however, is that ICANN was created and purpose-built to be the permanent and robust home of the IANA functions. Additionally, ICANN was structured from its inception to be inclusive, transparent and accountable.
The ICANN Board is both open to and encouraging of any improvements that bring greater visibility and understanding and greater assurance to the broad community that the IANA functions are performed in an absolutely reliable and accurate fashion for the benefit of all Internet users.
It has taken since 1998 to bring ICANN to a place where the NTIA was prepared to announce an intention to transfer the stewardship of the IANA Functions – a transition that was initially anticipated to occur in 2000. This is, in large part, what ICANN was designed to do, and we believe the considerable effort to date has yielded compelling results. Through this transition work, we have the opportunity to consider how to make the processes continue to work in an integrated fashion, as well as having the opportunity to establish and enhance mechanisms to hold the ICANN Board accountable if it were ever to interfere with the IANA Functions' operational role in performing actions based on policies developed by the community.
It is useful here to define the essential "IANA function," as distinct from ICANN's policy responsibilities. It is fundamentally clerical in nature. It is the publication of information provided by the creators of the information, with strong emphasis on accuracy, timeliness, and global availability.
- For the protocol parameters, the information is created by the IETF community.
- For numbers, the RIRs, in conjunction with their communities, determine the policies related to allocation of address blocks and autonomous system numbers.
- For names in the DNS root zone, the gTLD and ccTLD managers provide information about their TLD to IANA for either publication as WHOIS information, or for entry into the root of the DNS. Decisions about allocation of generic top-level domains (gTLDs) are managed by the Global Domains Division of ICANN executing policies determined by the GNSO. Decisions about allocation of country code top-level domains (ccTLDs) are documented in http://www.iana.org/domains/root.
While we have identified these concerns for CWG consideration in the next iteration of the proposal, the Board is supportive of many of the principles within the CWG proposal. For example, clear performance metrics and expectations are necessary for the proper operation of the IANA Functions operation, and the CWG proposal is impressive in its comprehensive identification of the services that are now housed within the IANA Functions Contract. As stated above, we agree with the principle of the functional separation between policy development and the execution of the IANA Functions Contract and we agree that a committee should be established to evaluate on an ongoing basis how the naming aspects of the IANA Function are being performed. This committee should be composed of people who understand the technical and operational issues across the ICANN community, with an emphasis on maintaining the security, stability, and resiliency of IANA operations and oversight.
Again, we look forward to the continued dialogue, and appreciate all the work and efforts undertaken by the community.
[1]http://www.ntia.doc.gov/speechtestimony/2014/remarksassistant-secretary-strickling-plifcba-telecommunications-policyregula