This Statement may be revised to provide further detail and clarity prior to the end of the Public Comment period.

Overview

The CWG is to be commended for its work at analysing options of replacing the NTIA stewardship of IANA. The resultant model has many good characteristics which will support the transition. The model has four basic components:

• Contract Co., the entity which to which NTIA will transfer the responsibility for IANA.
• The Multistakeholder Review Team (MRT) which will oversee most of the aspects of the IANA contract.
• The Customer Standing Committee (CSC) composed primarily of representatives of registry operators and will do routine review of IANA operations (set service levels and review reports).
• The Independent Appeal Panel (IAP) which will provide a mechanism for any affected party to challenge whether IANA has implemented policy properly.

The ALAC strongly supports the IAP. Although there have not been many cases where this has been needed, it is important to provide an appeal process should any of the concerned parties need it in the future. With the potential for redelegation of New gTLDs, this becomes even more important.

The ALAC supports the CSC, but does have some problems with both the composition of the CSC and the assignment of certain specific duties to it.

The ALAC supports the MRT concept, but has some very strong reservations about how it can be implemented in this proposed model.

The ALAC strongly opposes the concept and implementation of Contract Co. The creation of this entity is driven by the principle of separability – the ability to sever all ties between the IANA function and ICANN. All parties seem to believe that the current service level is high, and that there is no reason to consider such separation at the moment. Given that the price of the service is already zero, the only motivation for moving is that at some time in the future, the service level degrades or that ICANN otherwise mismanages or attempts to manipulate IANA. The ALAC believes that the Accountability CCWG can introduce changes to ICANN to ensure that such problems can be remedied without having to risk a transition to a brand new and untested IANA service to manage the Root Zone and without risking having to break the IANA Root Zone management from the other IANA functions (since it is unclear that the IETF and RIRs will be dissatisfied at the same time, or would choose to work with the MRT and Contract Co. to select a new IANA operator.

The core question is whether the complexity, cost and risks of the proposed model is worth the benefits of being able to separate from ICANN, or can we ensure that ICANN can be suitably controlled so as to allow a far simpler stewardship transition, and one where we preserve the current level of stability and security.

The ALAC understands that the CWG proposal is still being refined. When and if the issues raised in this paper are addressed, these changes will be duly considered.

Analysis

Contract Co.

There are a number of perceived potential problems with the concept of Contract Co. Some of them are unlikely, but since we are only establishing Contract Co. to cover the *possible* need to move from ICANN, we cannot ignore any problem areas with the solution. The security and stability of the root zone depends on it.

The following examples are not exhaustive, but will serve to illustrate the level of concern and potential for disruption.

Cost

It is unclear who will bear the costs associated with Contract Co. A suggestion has been made that the IANA contractor (ICANN for the moment) should bear all costs associated with Contract Co. (and of the other components of this model). There has been no formal assessment of these costs, but some estimates of the entire operation have been as high as a multiple of current IANA costs.

The possibility of litigation (see below) could push costs much higher.

Cost will either have to be borne by the direct customers of IANA (none of who now pay for the service) or by the IANA operator (currently ICANN).  Although the contract allows for fees to be levied under certain controlled circumstances, it has never been seriously considered, and if it were, the contract requires that they be based on direct costs and resources, not the infrastructure of Contract Co.

Although out of scope for this Names-related CWG, it is unlikely that the IETF and the RIRs would appreciate fees being levied. gTLD registries would likely be willing to pay fees if necessary, but would likely be unwilling to bear costs dis-proportionate with their usage of IANA. Although some ccTLDs might be willing to pay reasonable cost-based fees, that cannot be said of ccTLDs in general.

If costs are borne by the operator, to start, that would imply that ICANN pays for the infrastructure (and presumably start-up costs). ICANNs prime source of revenue is gTLD registrations and that implies that gTLD registrants, through registrar and registry fees, would bear the total cost.

Jurisdiction

The issue of “in what jurisdiction Contract Co. should be incorporated” has been raised repeatedly. The decision of which jurisdiction is ultimately selected may not have a great impact on Contract Co.’s operation, but it could ultimately be a question that is very difficult to resolve. There is some indication that the US government might require that it transfers the responsibility for IANA to a US-based corporation (in fact, the draft CWG proposal has place-holder text which says just that). There is, however, strong pressure from some quarters that this transition be used as the opportunity to reduce the US-centric control over core Internet resources.

The possible threat of nationalization is of course a critical decision point (see next point), as is the availability of litigation immunity if it is decided that it is a mandatory requirement.

Capture

The potential problem of Contract Co being “captured” has been discussed at length and the proponents of the model feel comfortable that it can be avoided. Many of these discussions have focused on the entire operation being taken over, and indeed, that may not be too likely. However, a more subtle form of capture is when the balance among stakeholders favors one group preferentially, effectively disenfranchising one or more other groups. With the unknown composition or formation processes for the MRT (which directs Contract Co.), this is potential problem.

One version of capture that has not been discussed is nationalization by the country in which Contract Co is incorporated or operates. One can readily imagine a situation where “in the interests of national security”, a government takes over Contract Co., violating one of the principle constraints on the NTIA transfer. Nationalization is not uncommon - http://en.wikipedia.org/wiki/Nationalization.

Litigation

Given that Contract Co. will be awarding a contract for a perceived valuable resource, and more particularly since some proponents of this model believe that there should be a mandatory RFP with the potential for moving the IANA resource, it is quite possible that an entity that loses the contract, or a bidder that is not selected could sue Contract Co. Contract Co. could also be the subject of malicious lawsuits. Regardless of the cause, such lawsuits could be expensive and time-consuming.

One particularly intriguing case study would be a losing contractor suing because IANA is about to be transferred to another entity, but at the same time, (as described under Costs), the losing contractor who still was the IANA operator at that moment, would be bound to cover the costs of defending it against its own lawsuit.

It has been proposed that in some jurisdictions, Contract Co. might be given immunity from civil lawsuit. That would certainly address this problem, but could ultimately cause others.

Rigidity

By its design, Contract Co would be very restricted in what it does. By its Articles of Incorporation and Bylaws it would be strictly bound to follow the instructions of the MRT, and its Board would be restricted from changing these rules. Such rigidity has been deemed to be necessary to ensure that its founding principles are honoured and it is bound to support its multistakeholder masters.

However, this very rigidity presumes that the world around Contract Co. will be stable and unchanging for the possible unlimited future. It is unclear how it might change if that was required to meet some unforeseen eventuality.

The only apparent option would be to give the MRT a capability of altering (or ordering to be altered) the core Contract Co. This presumes that there is no possibility whatsoever that the MRT itself could be corrupted (more on this later).

Contract Co. Misbehaviour

One cannot ignore the possibility of the Company Co. Board not following the rules under which it should be operating, or a Company Co. employee or contractor not following instructions and the Board not taking suitable corrective action.

The normal recourse in such a case it to have some harmed or interested party sue. If Company Co had received the protection from litigation that some proponents believe would be necessary, this recourse would not be available.

Risk

Any change implies some level of risk. A major change such as removing IANA from ICANN, with a potential result of it being taken over with no overlap of employees or systems would have a great risk of impacting security and stability. The concept of a mandatory RFP every N years has been pushed very strongly by some proponents of the model. Aside from the cost in both money and time on both the MRT and the RFP responder(s), such a process, regardless of a perceived need – essentially, change for the sake of change, is frightening!

Multistakeholder Review Team - MRT

The Multistakeholder Review Team is the core of the proposed model. It is essentially the operating arm of Contract Co., since it is delegated responsibility for determining the content of RFPs, evaluating their responses, determining the terms and conditions of contracts, evaluating overall performance, determining any remedial action necessary (up to and including breach and termination), budget review and performing a variety of activities currently performed by the NTIA. In earlier version of the model, it was named the Periodic Review Team with that the intent that it would only be convened when there was a specific task (such as an annual review) It has now been acknowledged that although it might not need to meet very regularly, it needs to be ready.

Quite simply, if the MRT cannot be assured to be 100% reliable, the entire model collapses.

It is unclear what entity or entities is envisioned as convening the MRT, establishing who is and is not an eligible stakeholder, how that evolves over time, whether the participants are remunerated or not and who funds it.

These are not trivial questions. It has been suggested that the MRT could be similar to the CWG itself, or the IANA ICG. But these are convened and funded by ICANN. In a scenario where Contract Co is compelled to separate IANA from ICANN, there is little reason to believe that ICANN would continue participating, or indeed if Contract Co. (and the MRT) would want and trust ICANN to play this role if the intent is complete separation.

Whoever convenes the MRT may consciously or unconsciously impact how MRT decisions are made based on the mix of stakeholders allowed to participate. It is easy to see these decisions at work. The IANA CWG (as an example), allows 2-5 Members per stakeholder including those outside the ICANN community and unlimited Participants. The Accountability CCWG also allows 2-5 Members and unlimited Participants, but no Members from outside of ICANN’s component organizations. At least one proposal for the MRT called for restricting some stakeholders to fewer seats than other stakeholders (GNSO@4, ccNSO@5, Root Servers@2, GAC, SSAC and ALAC@2 each). Each subtle difference impacts the decisions that the MRT will make.

Another unknown about the MRT is just what sort of entity it is. It will be referenced in Contract Co.’s articles of Incorporation and/or its Bylaws as the entity which will give Contract Co. its instructions and perform most of the work associated with Contract Co. It has not been specified just what this relationship is – a contract, a Memorandum of Understanding? Surely there will need to be SOME document describing the relationship and the responsibilities of both parties. We have been told repeatedly that only formally incorporated bodies can enter into such agreements without having the individual participants personally liable for actions of the entity.      

One possible option that removes this unknown is to have the MRT as a component part of Contract Co. But at that stage, Contract Co. is no longer a bare-bones entity and in fact has become a mini-ICANN, soothing that we were trying to avoid. So we are back with a large question mark here.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

Customer Standing Panel - CSC

If the CSC is restricted to making mechanical decision on IANA performance, the current proposal may well work. The ALAC believe that regardless of the function, there should be a substantive multistakeholder component.

The description of the CSC says that it will take over the NTIA responsibility of reviewing redelegations. Later in the draft proposal, it says “Contractor shall submit its recommendations to the [[CSC] or [MRT] or [RZM[1]] or [Independent Evaluator]] via a Delegation and Redelegation Report.” Certainly if the CSC is largely populated by registry operators, there is no reason to believe that they are the proper authority for this task. More on this later.

Since it has been suggested that the MRT will meet only when there is an explicit task for it to do (or perhaps on a monthly basis), and it is not tasked with routine monitoring of IANA, no one is monitoring whether IANA is following policy. Clearly that needs to be rectified. If the MRT is to only meet when called upon, then the only body left to do this is the CSC. If the CSC were to be tasked with monitoring adherence to policy, it MUST have a very significant multistakeholder component. The reason is that at least for the gTLDs, the policy process allows the GNSO to adopt policy which affects registries but without the support of the Registry Stakeholder Group. In such a case, it could be to in the interest of registries, who did not want the policy in the first place, to have IANA not follow it. The body that monitors that policy is carried out, if it is comprised of some stakeholders, must have a composition comparable to the body that set the policy.

Independent Appeal Panel - IAP

The ALAC is largely satisfied with the IAP as specified in the proposal. It has been suggested that there should be an associated mechanism to ensure the pending an appeal, the action being objected to might need to be delayed pending the appeal.

Missing Components

As already mentioned, it is unclear who, on a day to day basis, will be responsible for ensuring that policy is adhered to. Currently the NTIA has the ability to do that. Also, if some part of ICANN notices that there is a problem, they must have standing to take action within ICANN (in a world where ICANN no longer has a connection with IANA).

In the new model, even if the GNSO were to notice a problem (and they are not staffed to do so), they would have no standing whereby they could take action.

A related issue, as already briefly mentioned, is redelegations. It seems that some parties believe that the IAP is sufficient to rectify any problems, but others feel that the NTIA “backstop” function must be replaced, and it is far from clear how that can be done. In the ccTLD space, the Framework of Interpretation may make redelegations less subject to problems, but in the gTLD space, where such redelegations may have very high financial values attached to them, there must be some level of control.

ALAC Proposal

As indicated by our analysis, the ALAC believes that:

• there a large number of problems associated with the draft proposal;
• although  many might be solvable, some seem less likely to be addressed in a practical way;
• The overall structure is complex and will be costly,
• The benefits it attempts to deliver are available in other less complex and costly ways.

Recommendation 1

The Contract Co. entity should be eliminated and the assignment of IANA should be made by the NTIA to ICANN. This will drastically reduce the cost one-time and ongoing costs of the transition.

The Accountability CCWG should be charged with ensuring that the objectives associated with the Contract Co. can be met within the ICANN structure.

Although the details of such measures are outside of the scope of the IANA Stewardship CWG, the ALAC feels that it is necessary to demonstrate that the task presented to the Accountability CCWG is not an impossible one. Towards that end, the ALAC offers some measures that the CCWG could implement should it so decide:

• Requirement that MRT recommendations are adhered to. This is essentially the exact same rule as Contract Co. would have been subject to. Should that not be possible under applicable corporate law, binding arbitration could be used to ensure that advice is duly considered. ICANN already accepts the concept of binding arbitration in its contracts.
• In addition to the MRT, and IANA Support Organization could be established. Conceivably, with suitable powers, the IANA Supporting Organization (ISO?) could be one and the same organization. But that would presume that an entity within ICANN could be given the necessary authority.
• Changes with respect to IANA would be subject to advance notice, public comment and MRT approval, and would require significant Board voting thresholds (percentage of those voting for a change and/or absolute number of votes required.
• ACs and SOs could be allowed to recall their Board members. Such action could temporarily reduce the size of the Board (until replacement members are appointed) to freeze any Board action on critical IANA issues.
• In extreme cases, the MRT could require mandatory divestiture of IANA, with the same ultimate effect of Contract Co. moving IANA to a new contractor. The MRT would specify the details of such divestiture, and the attributes of the prospective recipient of the IANA functions. If necessary, the MRT could even require the creation of a Contract Co.-like entity, but this would only need to be done if it was clear that ICANN was no longer a suitable vehicle for IANA. This last option provides the separability of ICANN and IANA, but does not build the entire infrastructure required to do so until and unless there is evidence that it is required.

The net impact would be that ICANN would be subject to constraints with respect to IANA similar to those of Contract Co, without the complexity and cost of building, supporting and defending the new infrastructure.

Recommendation 2

The MRT should be convened by ICANN, similar to how it has convened the Stewardship CWG, the Accountability CCWG, and most particularly, the IANA ICG. ICANN has demonstrated an ability and willingness to create such groups. Moreover, in the process we have learned a lot about how this should be done, so the process should only get better.

Convening the MRT under the auspices of ICANN, in conjunction with its ACs and SOs and the I* family of organizations can ensure that all MSs are covered and treated equitably.

Whether the MRT resides within the bounds of ICANN, or is created as an entity external to ICANN is an issue that the Accountability CCWG would have to investigate (depending on which structure would be optimal given any corporate law restrictions).

As another way forward, the MRT could be replaced by a dual-pronged vehicle similar to that used by the addressing community. In that case, there is the Address Supporting Organization (ASO) and the ASO Address Council contained wholly within ICANN, and the Number Resource Organization (NRO) external to ICANN. In the case of IANA, there might be an IANA Support Organisation (ISO) and the IANA Resource Organization (IRO). The latter could be established in coordination with the other I* organizations and would afford a strong measure on continuity should the option of divesting IANA ever be needed.

Recommendation 3

There is a serious gap in all proposals related to a viable way to replace the NTIA backstop functions, particularly those sensitive ones related to redelegations. The IAP may be a way of correcting a perceived error, or with suitable delay and injunctive procedures, perhaps even a way to prevent them, but there should be “standard operating procedure” way of catching most such errors without resorting to the appeals process.

There is no evidence that any solution or partial solution proposed to date is directly related to the presence of Contract Co or not (since Contract Co. itself only follows instructions from other bodies that will continue to exist in the ALAC proposal).

Although the ALAC does not have specific recommendations at this time, we believe that identifying an equitable solution is critical to an effective stewardship transition

Recommendation 4

Ongoing monitoring ensuring that IANA is adhering to policy is an essential part of any transition. In the ALAC proposal, this could be done with relation to names/root zone by some combination of the appropriate SOs (with suitable staff support), since they are the ones that have created the policies, the MRT, the CSC (with suitable MS components added), or an IANA Support Organization if that were to be created. The Accountability CCWG would no doubt need to ensure that they had standing to take action on perceived violations.

This Statement may be revised to provide further detail and clarity prior to the end of the Public Comment period.

Overview

The CWG is to be commended for its work at analysing options of replacing the NTIA stewardship of IANA. The resultant model has many good characteristics which will support the transition. The model has four basic components:

• Contract Co., the entity which to which NTIA will transfer the responsibility for IANA.
• The Multistakeholder Review Team (MRT) which will oversee most of the aspects of the IANA contract.
• The Customer Standing Committee (CSC) composed primarily of representatives of registry operators and will do routine review of IANA operations (set service levels and review reports).
• The Independent Appeal Panel (IAP) which will provide a mechanism for any affected party to challenge whether IANA has implemented policy properly.

The ALAC strongly supports the IAP. Although there have not been many cases where this has been needed, it is important to provide an appeal process should any of the concerned parties need it in the future. With the potential for redelegation of New gTLDs, this becomes even more important.

The ALAC supports the CSC, but does have some problems with both the composition of the CSC and the assignment of certain specific duties to it.

The ALAC supports the MRT concept, but has some very strong reservations about how it can be implemented in this proposed model.

The ALAC strongly opposes the concept and implementation of Contract Co. The creation of this entity is driven by the principle of separability – the ability to sever all ties between the IANA function and ICANN. All parties seem to believe that the current service level is high, and that there is no reason to consider such separation at the moment.Given that the price of the service is already zero, the only motivation for moving is that at some time in the future, the service level degrades or that ICANN otherwise mismanages or attempts to manipulate IANA. The ALAC believes that the Accountability CCWG can introduce changes to ICANN to ensure that such problems can be remedied without having to risk a transition to a brand new and untested IANA service to manage the Root Zone and without risking having to break the IANA Root Zone management from the other IANA functions (since it is unclear that the IETF and RIRs will be dissatisfied at the same time, or would choose to work with the MRT and Contract Co. to select a new IANA operator.

The core question is whether the complexity, cost and risks of the proposed model is worth the benefits of being able to separate from ICANN, or can we ensure that ICANN can be suitably controlled so as to allow a far simpler stewardship transition, and one where we preserve the current level of stability and security.

Analysis

Contract Co.

There are a number of perceived potential problems with the concept of Contract Co. Some of them are unlikely, but since we are only establishing Contract Co. to cover the *possible* need to move from ICANN, we cannot ignore any problem areas with the solution. The security and stability of the root zone depends on it.

The following examples are not exhaustive, but will serve to illustrate the level of concern and potential for disruption.

Cost

It is unclear who will bear the costs associated with Contract Co. A suggestion has been made that the IANA contractor (ICANN for the moment) should bear all costs associated with Contract Co. (and of the other components of this model). There has been no formal assessment of these costs, but some estimates of the entire operation have been as high as a multiple of current IANA costs.

The possibility of litigation (see below) could push costs much higher.

Cost will either have to be borne by the direct customers of IANA (none of who now pay for the service) or by the IANA operator (currently ICANN).  Although the contract allows for fees to be levied under certain controlled circumstances, it has never been seriously considered, and if it were, the contract requires that they be based on direct costs and resources, not the infrastructure of Contract Co.

Although out of scope for this Names-related CWG, it is unlikely that the IETF and the RIRs would appreciate fees being levied. gTLD registries would likely be willing to pay fees if necessary, but would likely be unwilling to bear costs dis-proportionate with their usage of IANA. Although some ccTLDs might be willing to pay reasonable cost-based fees, that cannot be said of ccTLDs in general.

If costs are borne by the operator, to start, that would imply that ICANN pays for the infrastructure (and presumably start-up costs). ICANNs prime source of revenue is gTLD registrations and that implies that gTLD registrants, through registrar and registry fees, would bear the total cost.

Jurisdiction

The issue of “in what jurisdiction Contract Co. should be incorporated” has been raised repeatedly. The decision of which jurisdiction is ultimately selected may not have a great impact on Contract Co.’s operation, but it could ultimately be a question that is very difficult to resolve. There is some indication that the US government might require that it transfers the responsibility for IANA to a US-based corporation (in fact, the draft CWG proposal has place-holder text which says just that). There is, however, strong pressure from some quarters that this transition be used as the opportunity to reduce the US-centric control over core Internet resources.

The possible threat of nationalization is of course a critical decision point (see next point), as is the availability of litigation immunity if it is decided that it is a mandatory requirement.

Capture

The potential problem of Contract Co being “captured” has been discussed at length and the proponents of the model feel comfortable that it can be avoided. Many of these discussions have focused on the entire operation being taken over, and indeed, that may not be too likely. However, a more subtle form of capture is when the balance among stakeholders favors one group preferentially, effectively disenfranchising one or more other groups. With the unknown composition or formation processes for the MRT (which directs Contract Co.), this is potential problem.

One version of capture that has not been discussed is nationalization by the country in which Contract Co is incorporated or operates. One can readily imagine a situation where “in the interests of national security”, a government takes over Contract Co., violating one of the principle constraints on the NTIA transfer. Nationalization is not uncommon - http://en.wikipedia.org/wiki/Nationalization.

Litigation

Given that Contract Co. will be awarding a contract for a perceived valuable resource, and more particularly since some proponents of this model believe that there should be a mandatory RFP with the potential for moving the IANA resource, it is quite possible that an entity that loses the contract, or a bidder that is not selected could sue Contract Co. Contract Co. could also be the subject of malicious lawsuits. Regardless of the cause, such lawsuits could be expensive and time-consuming.

One particularly intriguing case study would be a losing contractor suing because IANA is about to be transferred to another entity, but at the same time, (as described under Costs), the losing contractor who still was the IANA operator at that moment, would be bound to cover the costs of defending it against its own lawsuit.

It has been proposed that in some jurisdictions, Contract Co. might be given immunity from civil lawsuit. That would certainly address this problem, but could ultimately cause others.

Rigidity

By its design, Contract Co would be very restricted in what it does. By its Articles of Incorporation and Bylaws it would be strictly bound to follow the instructions of the MRT, and its Board would be restricted from changing these rules. Such rigidity has been deemed to be necessary to ensure that its founding principles are honoured and it is bound to support its multistakeholder masters.

However, this very rigidity presumes that the world around Contract Co. will be stable and unchanging for the possible unlimited future. It is unclear how it might change if that was required to meet some unforeseen eventuality.

The only apparent option would be to give the MRT a capability of altering (or ordering to be altered) the core Contract Co. This presumes that there is no possibility whatsoever that the MRT itself could be corrupted (more on this later).

Contract Co. Misbehaviour

One cannot ignore the possibility of the Company Co. Board not following the rules under which it should be operating, or a Company Co. employee or contractor not following instructions and the Board not taking suitable corrective action.

The normal recourse in such a case it to have some harmed or interested part sue. If Company Co had received the protection from litigation that some proponents believe would be necessary, this recourse would not be available.

Risk

Any change implies some level of risk. A major change such as removing IANA from ICANN, with a potential result of it being taken over with no overlap of employees or systems would have a great risk of impacting security and stability. The concept of a mandatory RFP every N years has been pushed very strongly by some proponents of the model. Aside from the cost in both money and time on both the MRT and the RFP responder(s), such a process, regardless of a perceived need – essentially, change for the sake of change, is frightening!

Multistakeholder Review Team - MRT

The Multistakeholder Review Team is the core of the proposed model. It is essentially the operating arm of Contract Co., since it is delegated responsibility for determining the content of RFPs, evaluating their responses, determining the terms and conditions of contracts, evaluating overall performance, determining any remedial action necessary (up to and including breach and termination), budget review and performing a variety of activities currently performed by the NTIA. In earlier version of the model, it was named the Periodic Review Team with that the intent that it would only be convened when there was a specific task (such as an annual review) It has now been acknowledged that although it might not need to meet very regularly, it needs to be ready.

Quite simply, if the MRT cannot be assured to be 100% reliable, the entire model collapses.

It is unclear what entity or entities is envisioned as convening the MRT, establishing who is and is not an eligible stakeholderhow that evolves over time, whether the participants are remunerated or not and who funds it.

These are not trivial questions. It has been suggested that the MRT could be similar to the CWG itself, or the IANA ICG. But these are convened and funded by ICANN. In a scenario where Contract Co is compelled to separate IANA from ICANN, there is little reason to believe that ICANN would continue participating, or indeed if Contract Co. (and the MRT) would want and trust ICANN to play this role if the intent is complete separation.

Whoever convenes the MRT may consciously or unconsciously impact how MRT decisions are made based on the mix of stakeholders allowed to participate. It is easy to see these decisions at work. The IANA CWG (as an example), allows 2-5 Members per stakeholder including those outside the ICANN community and unlimited Participants. The Accountability CCWG also allows 2-5 Members and unlimited Participants, but no Members from outside of ICANN’s component organizations. At least one proposal for the MRT called for restricting some stakeholders to fewer seats than other stakeholders (GNSO@4, ccNSO@5, Root Servers@2, GAC, SSAC and ALAC@2 each). Each subtle difference impacts the decisions that the MRT will make.

Another unknown about the MRT is just what sort of entity it is. It will be referenced in Contract Co.’s articles of Incorporation and/or its Bylaws as the entity which will give Contract Co. its instructions and perform most of the work associated with Contract Co. It has not been specified just what this relationship is – a contract, a Memorandum of Understanding? Surely there will need to be SOME document describing the relationship and the responsibilities of both parties. We have been told repeatedly that only formally incorporated bodies can enter into such agreements without having the individual participants personally liable for actions of the entity.      

One possible option that removes this unknown is to have the MRT asa component part of Contract Co. But at that stage, Contract Co. is no longer a bare-bones entity and in fact has become a mini-ICANN, soothing that we were trying to avoid. So we are back with a large question mark here.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

Customer Standing Panel - CSC

If the CSC is restricted to making mechanical decision on IANA performance, the current proposal may well work. The ALAC believe that regardless of the function, there should be a substantive multistakeholder component.

The description of the CSC says that it will take over the NTIA responsibility of reviewing redelegations. Later in the draft proposal, it says “Contractor shall submit its recommendations to the [[CSC] or [MRT] or [RZM[1]] or [Independent Evaluator]] via a Delegation and Redelegation Report.” Certainly if the CSC is largely populated by registry operators, there is no reason to believe that they are the proper authority for this task. More on this later.

Since it has been suggested that the MRT will meet only when there is an explicit task for it to do (or perhaps on a monthly basis), and it is not tasked with routine monitoring of IANA, no one is monitoring whether IANA is following policy. Clearly that needs to be rectified. If the MRT is to only meet when called upon, then the only body left to do this is the CSC. If the CSC were to be tasked with monitoring adherence to policy, it MUST have a very significant multistakeholder component. The reason is that at least for the gTLDs, the policy process allows the GNSO to adopt policy which affects registries but without the support of the Registry Stakeholder Group. In such a case, it could be to in the interest of registries, who did not want the policy in the first place, to have IANA not follow it. The body that monitors that policy is carried out, if it is comprised of some stakeholders, must have a composition comparable to the body that set the policy.

Independent Appeal Panel - IAP

The ALAC is largely satisfied with the IAP as specified in the proposal. It has been suggested that there should be an associated mechanism to ensure the pending an appeal, the action being objected to might need to be delayed pending the appeal.

Missing Components

As already mentioned, it is unclear who, on a day to day basis, will be responsible for ensuring that policy is adhered to. Currently the NTIA has the ability to do that. Also, if some part of ICANN notices that there is a problem, they must have standing to take action within ICANN (in a world where ICANN no longer has a connection with IANA).

In the new model, even if the GNSO were to notice a problem (and they are not staffed to do so), they would have no standing whereby they could take action.

A related issue, as already briefly mentioned, is redelegations. It seems that some parties believe that the IAP is sufficient to rectify any problems, but others feel that the NTIA “backstop” function must be replaced, and it is far from clear how that can be done. In the ccTLD space, the Framework of Interpretation may make redelegations less subject to problems, but in the gTLD space, where such redelegations may have very high financial values attached to them, there must be some level of control.

ALAC Proposal

As indicated by our analysis, the ALAC believes that:

• there a large number of problems associated with the draft proposal;
• although  many might be solvable, some seem less likely to be addressed in a practical way;
• The overall structure is complex and will be costly,
• The benefits it attempts to deliver are available in other less complex and costly ways.

Recommendation 1

The Contract Co. entity should be eliminated and the assignment of IANA should be made by the NTIA to ICANN. This will drastically reduce the cost one-time and ongoing costs of the transition.

The Accountability CCWG should be charged with ensuring that the objectives associated with the Contract Co. can be met within the ICANN structure.

Although the details of such measures are outside of the scope of the IANA Stewardship CWG, the ALAC feels that it is necessary to demonstrate that the task presented to the Accountability CCWG is not an impossible one. Towards that end, the ALAC offers some measures that the CCWG could implement should it so decide:

• Requirement that MRT recommendations are adhered to. This is essentially the exact same rule as Contract Co. would have been subject to. Should that not be possible under applicable corporate law, binding arbitration could be used to ensure that advice is duly considered. ICANN already accepts the concept of binding arbitration in its contracts.
• In extreme cases, the MRT could require mandatory divestiture of IANA, with the same ultimate effect of Contract Co. moving IANA to a new contractor. The MRT would specify the details of such divestiture, and the attributes of the prospective recipient of the IANA functions. If necessary, the MRT could even require the creation of a Contract Co.-like entity, but this would only need to be done if it was clear that ICANN was no longer a suitable vehicle for IANA.
• In addition to the MRT, and IANA Support Organization could be established. Conceivably, with suitable powers, the IANA Supporting Organization (ISO?) could be one and the same organization. But that would presume that an entity within ICANN could be given the necessary authority.
• Changes with respect to IANA would be subject to advance notice, public comment and MRT approval, and would require significant Board voting thresholds (percentage of those voting for a change and/or absolute number of votes required.
• ACs and SOs could be allowed to recall their Board members. Such action could temporarily reduce the size of the Board (until replacement members are appointed) to freeze any Board action on critical IANA issues.

The net impact would be that ICANN would be subject to constrints with respect to IANA similar to those of Contract Co, without the complexity and cost of building, supporting and defending the new infrastructure.

Recommendation 2

The MRT should be convened by ICANN, similar to how it has convened the Stewardship CWG, the Accountability CCWG, and most particularly, the IANA ICG. ICANN has demonstrated an ability and willingness to create such groups. Moreover, in the process we have learned a lot about how this should be done, so the process should only get better.

Convening the MRT under the auspices of ICANN, in conjunction its ACs and SOs and the I* family of organizations can ensure that all MSs are covered and treated equitably.

Whether the MRT resides within the bounds of ICANN, or is created as an entity external to ICANN is an issue that the Accountability CCWG would have to investigate (depending on which structure would be optimal given any corporate law restrictions).

Recommendation 3

There is a serious gap in all proposals related to a viable way to replace the NTIA backstop functions, particularly those sensitive ones related to redelegations. The IAP may be a way of correcting a perceived error, or with suitable delay and injunctive procedures, perhaps even a way to prevent them, but there should be “standard operating procedure” way of catching most such errors without resorting to the appeals process.

There is no evidence that any solution or partial solution proposed to date is directly related to the presence of Contract Co or not (since Contract Co. itself only follows instructions from other bodies that will continue to exist in the ALAC proposal).

Although the ALAC does not have specific recommendations at this time, we believe that identifying an equitable solution is critical to an effective stewardship transition

Recommendation 4

Ongoing monitoring ensuring that IANA is adhering to policy is an essential part of any transition. In the ALAC proposal, this could be done with relation to names/root zone by some combination of the appropriate SOs (with suitable staff support), since they are the ones that have created the policies, the MRT, the CSC (with suitable MS components added), or an IANA Support Organization if that were to be created. The Accountability CCWG would no doubt need to ensure that they had standing to take action on perceived violations.

Reference Document 

• Presentation of Proposed ALAC Statement (Alan Greenberg)
• Preliminary Draft Statement - PDF - Presented at 10 December 2014 Webinar
• Slides - Presented at 10 December 2014 Webinar
• Draft Statement - PDF - Redline version compared to Webinar