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