Home»Documents»IAB Correspondence, Reports, and Selected Documents»2015»IAB comments on the CCWG accountability 2d draft report
On 9 September 2015, the IAB sent correspondence to the ICANN Cross Community Working Group on Enhancing ICANN Accountability. The text of that correspondence is as follows:
To the ICANN Cross Community Working Group on Enhancing ICANN Accountability: The Internet Architecture Board (IAB) thanks the CCWG-Accountability (henceforth, "CCWG") for their work and would like to express our appreciation for the opportunity to comment on this draft. The IAB continues to believe that the time is right for the transition away from a US Government role in IANA stewardship, and recognizes the requirement of the IANA names community for accountability changes to ICANN in support of that transition. In the course of its review, the IAB noted a few items for which we seek clarification or adjustment. These are set out below in part I of our response; we regard these as changes we think are necessary for the IAB to support the proposal. The IAB also has some observations relevant to the CCWG's proposal, which we set out in part II of our response; these we do not regard as directly relevant to the IAB's specific concerns with respect to the operation of IANA. We offer them not as directly related to our role in the IETF relationship with IANA, but as general observations on what RFC 2850 calls "procedures used by the Internet." We do not regard these as lesser observations, but distinguish them as observations not directly related to our role in managing the IETF relationship to IANA. If you have questions or require further information, please let us know. We remain supportive of all efforts to ensure the overall operation of every IANA function is responsive to the needs of the Internet as a whole, and offer these remarks in that spirit of collaboration. PART I: Clarification related to IAB and IETF relationship to IANA As currently defined, the Independent Review Process (IRP) appears to cover the work of IANA in populating the protocol parameter registries. Oversight of IANA operations related to protocol parameters are not fundamentally reliant on general ICANN accountability enhancements, while such improvements are of course useful. The purpose of our response is to ensure that the clear division of responsibility is maintained throughout the text. The IETF has well-tested appeals processes for decisions related to these registries that are documented in the IETF contribution to the IANA Stewardship Transition Coordination Group's (ICG) proposal. In particular, we wish to bring to your attention the Memorandum of Understanding between the IETF (including the IAB) and ICANN, dated 1 March 2000, documented in RFC 2860. Section 4.2 of that document makes clear that any disputes regarding protocol parameters are to be resolved by the IAB. A parallel process would be counter-productive, and would be in conflict with that MoU. Therefore, we expect to see protocol parameter-related IANA activities removed from the scope of the IRP, just as issues related to number resource IANA activities are excluded. To address this specific concern, we propose that a new exclusion be added to Section 5.1 below (9) as follows: 9(add) Exclusions: Protocol Parameters: In accordance with an existing agreement, the Internet Architecture Board (IAB) is responsible for resolving disputes involving protocol parameters, and as such disputes are to be addressed in accordance with the Memorandum of Understanding between the IAB, IETF, and ICANN, dated March 1, 2000. In general, we believe that the IRP process should be narrowly tailored to names-related IANA actions. The expertise requested of panelists seems to assume this scope, but the limitation is not effectively stated within the document. The document could now be read to imply that an IRP could be convened for any matter touching on the Core Values. This is inconsistent with the enumerated powers for ICANN, as well as raising the issues with conflicting appeals processes and the existing agreement noted above. The most effective method of resolving this concern is recasting the Core Values themselves so that each relies directly on ICANN’s mandate in an area of policy. The IAB previously suggested a way to make the limit explicit in the mission statement within the bylaws, but the CCWG did not incorporate that recommendation in the latest draft. We ask that this be reconsidered, and we reiterate this core element of our previous proposal: “The mission of The Internet Corporation for Assigned Names and Numbers (“ICANN”) is to support, at the overall level, core Internet registries, and in particular to ensure the stable and secure operation of those registries.” In making this change (around ¶169 in the current draft), most of the following clarifying material could be removed, because of the limitation of scope already in place. Moreover, the explicit limitation of the scope of the IRP should be added either to the purpose or role of IRP, around ¶ 268. This is especially important because the actual bylaw text necessary for the new IRP appears to be deferred until Work Stream 2. The IAB believes that limitations on the scope of ICANN's normative Core Values and independent review system must be in place before the proposal from the ICG, which depends on the output of the CCWG, can be properly implemented. Lastly, while the IAB understands and supports the community requirement for budgetary review, we believe that the proposed mechanism presents a potential operational problem. As put forward in Section 7.1, the veto process may apply independently to the ICANN budget and a separated IANA function budget. After the Post-Transition IANA (PTI) is created, the funds available for the IANA function budget would be the funds transferred from ICANN to PTI or, potentially, to a different Independent Functions Operator (IFO). The veto process for IANA funding does not, however, appear to match the legal structure contemplated in the ICG proposal. The proposal is to create an independent legal entity (IFO) that performs its duties under a contract with ICANN, while ICANN is formally responsible for the IANA functions for the numbers and protocol parameters communities under memoranda of understanding. If a veto or succession of vetoes held the budget available for transfer to PTI at a fixed level, the result might be that ICANN would be unable to meet its obligation under these agreements. Such a default would, of course, present a problem for both ICANN and the IFO in bypassing the protections specific to the IANA budget. We therefore suggest an amendment of ¶382 of the proposal. The concern could be addressed by two additional sentences: "In the event that the overall ICANN budget were to be vetoed, while the IANA Budget were approved, the ICANN caretaker budget would automatically be adjusted if necessary to include any increase in the required IANA Budget. Funds necessary from ICANN for the IANA Budget (whether under a caretaker budget for IANA or under a fully-approved IANA Budget, as appropriate) would not, under any circumstances, be withheld from the IANA Functions Operator due to a lack of a budget for ICANN." As an alternative, the IAB suggests that the community review of the IANA budget be conducted via review of the contract between ICANN and the IFO. That review would be conducted whenever an IFO contract is set, amended, or renewed. We further suggest that such contract review also include both the numbers community and protocol parameters community, since each is responsible for aspects of IANA work, regardless of whether it is delivered by directly by ICANN or indirectly through a subcontractor. PART II: Observations not related specifically to the relationship among the IETF, IAB, and IANA. As we understand the process, this first stream of CCWG work ("Work Stream 1") is intended to propose the minimal changes necessary to meet the needs articulated by the ICANN Cross Community Working Group to Develop an IANA Stewardship Transition Proposal on Naming Related Functions ("the CWG"). Those needs are now incorporated in the proposal from the ICG. We believe that the needs identified by the CWG are large, and so it is not surprising that the CCWG's draft contains a large number of changes to ICANN. In particular, the CCWG draft includes the proposal for the "Community Mechanism as Sole Member Model" (henceforth, the "sole member model"). Because the ICG proposal (particularly in the names function) depends upon the proposals from the CCWG, these changes are critical to the IANA stewardship transition away from the NTIA. The IAB observes that the sole member model creates an entirely new mechanism that is so far untested. Moreover, the new mechanism will be highly resistant to change, because the sole member will be able to veto bylaw changes that alter its behavior. Given ICANN's central position in IANA functions, even after the transition, the untested nature of this change bears scrutiny. The IAB believes that, in general, it is desirable to avoid changing many things all at once, on the grounds that evolutionary change is less risky. A key reason why the Internet -- both technology and administration -- has been successful is that the community has followed a model of stepwise changes, where those elements that are mature and well-understood are adopted while other innovations are allowed to come to maturity. We embrace that tradition. Moreover, the current efforts are being undertaken in a hurry, in order to meet the needs of the transition timeline. We believe that any large and seemingly-permanent change must be undertaken with great care, and not in haste. We wonder whether there might be ways to adapt existing institutions and mechanisms to meet, on an interim basis, the immediate accountability needs specified in the ICG proposal. If such smaller changes could be acceptable as an interim step, the transition could proceed separately from large-scale organizational changes to ICANN. The current proposal from the CCWG could continue to be refined in Work Stream 2, and could be implemented as community consensus is reached. The IAB is conscious that the CCWG has worked long and hard on its proposal, and that it has investigated several alternatives, so we are not going to try to come up with a complete alternative proposal in this comment. At the same time, given the pressure from the calendar and the extent of change needed, we are hopeful that some interim steps could be contemplated. We undertook a quick and admittedly incomplete analysis in the hope of making a useful suggestion without pretending to offer a full alternative proposal. It led us to suspect that the powers actually needed to achieve the CWG's enumerated needs could be satisfied with some additional powers to the ICANN Nomcom, until such time as a more satisfactory arrangement could be reached. It seems that, if a sitting Nomcom could (for any reason) recall some or all of Nomcom appointees to the Board (with some suitably high threshold of members), and the ACs and SOs could (again for any reason) recall their own appointees (using a similar threshold), then the effective power necessary would be in place to achieve the immediate needs. Budget disputes might be solved the same way, or might just depend on the power to replace the Board. This would certainly not provide the legal enforceability that the CCWG aims to provide in its report. The point of our suggestion, however, is to make enough of a change now to enable the transition; provide the community with the power the CWG has identified needing; and encourage the community to arrive at future, more satisfying, and more regular means to achieve the ends. It might be that these interim measures, combined with the CCWG's contemplated IRP or something like it, would be enough to permit incremental improvement, including the transition. The idea in general is to make modest changes to an existing and reasonably well-understood (and already functioning) mechanism, avoid fundamental changes to the nature of ICANN, and find something that can be implemented in a fairly short time and then refined with a high chance of success. It need not, and probably should not, be a permanent change, but it would allow the CCWG to continue its important efforts in Work Stream 2 without the deadline pressure created by the needs of the transition. We are thankful to the CCWG for the enormous work it has already put in, and hope that the above contribution is understood to be a constructive suggestion, which is the spirit in which it is offered. We believe that the whole Internet community will yet collaborate to produce a durable but flexible means to achieve our shared goal of a stable transition within the time we have. We prefer that shared future to one in which the different communities drift apart and undertake independent arrangements for their registration functions. Respectfully submitted, Andrew Sullivan For the IAB