Moderator: Gisella Gruber-White
February 3, 2015
3:00 pm CT
Grace Abuhamad: Welcome everyone to the Second Webinar for the CWG. It is now 2100 UTC. Your presenter today is one of the co-Chairs of the Cross Community Working Group, Lise Fuhr. So I'll turn it over to her. Thank you Lise.
Lise Fuhr: Hi and welcome everyone. As Grace said, I'm one of the co-Chairs for the IANA Stewardship Cross Community Working Group. And I will present on this Webinar. This Webinar is about where we are regarding our work for the CWG. And I will start with a brief presentation of the background of this group.
Well, the U.S. Government announced in March 2014 that they intended to transition its stewardship to the global multi stakeholder community. And as you might know, the U.S. Government set some requirements on this transition.
First of all, they want any proposal to address the following four principles. It had to support an enhanced multi stakeholder model. It had to maintain security and stability and resiliency of the Internet DNS. It had to meet the needs and expectations of the global customers and partners of the IANA services. And it had to maintain the openness of the Internet.
And finally, the NTIA stated that a proposal that replaces NTIA could not be government led or an intergovernmental organization. So these were the requirements from the NTIA.
And the next slide is a brief overview of the IANA functions. And I will not - it doesn't present well on the screen and it's meant for you to have so you can go back and study if you wish to do so later.
The next slide is the high level overview of the IANA Stewardship process and the ICANN Accountability process. These two groups are interlinked and Workstream 1 of the accountability is focused on enhancing any accountability that needs to be in place within the timeframe of the IANA transition.
So if we got further, you can - the IANA Stewardship actually included three groups; the naming community, the numbering communities and the protocols. And therefore IANA established - not IANA, sorry. ICANN established a coordination group.
And this coordination group should have representation and have representation from all stakeholders. The community will self-select its members and it has to establish all working methods and modes of operation. And it was encouraged to adhere to diversity standards. This working group is supported by an independent and non-ICANN staff Secretariat.
So in this process ICANN serves as a convener and facilitator and ICANN remains neutral and provides engagement and (outreach) travel and additional support services for the group.
So the main task of this coordination group, the IANA Stewardship Transition Coordination Group, that is in short the ICG, is actually to be (allies) to all interested parties, to access the outputs of the three operational communities for compatibility and interoperability and the three communities were - that's naming community, the numbering and the protocols.
And the group has to sample a complete proposal for the actual transition and to share the information and communicate with the public. So in order to do that, the ICG made a request for proposal that's having the following elements.
Well, a description of the community's use of IANA functions were one part of it. And a description of the function, what is the customers of the function, what are the registries involved in providing the functions and a description of any overlaps or interdependencies between the communities' IANA requirements. And they also wanted existing pre-transition arrangements; what are the policy sources; and oversight and accountability.
So any proposed post-transition oversight and accountability arrangement needs to be in place. And you also need to make an assessment of the transition's implications.
So while the request was sent to the three organizations, as you see that the main names were cross community working group. And we have the numbering resources, the CRISP Team, the consolidated RAR, IANA Stewardship Proposal Team and the protocol parameters, the IANA plan working group.
So these three communities went into discussions and as you see while the CRISP Team on numbering has submitted their proposal. The IANA plan has as of 6 January submitted their proposal to the ICG whereas the CWG stewardship has, well, developed the proposal. The proposal has been posted for public comment during December.
And there was an intensive work weekend in January. And after this the group concluded that we need more time. Part of this Webinar is to describe and explain why more time is needed. So in the following presentation I will describe where the CWG are at the moment.
Well, the CWG IANA group is consisting of 134 people. As you can see on the slide those are nine members and 115 participants. The members are those that are chosen by organizations (define) the charter for the group. These are the ccNSO; the Governmental Advisory Committee, GAC; the GNSO; the ALAC; and the SSAC.
The rest is participants but because this group is open for anyone to join, it has also been decided that you don't distinguish between participant and members. They're equally participants in the group. The only difference is of course the funding that's been given for the traveling to the face-to-face meeting in Frankfurt where some of the participants were funding their own expenses.
So well, we have been meeting weekly in the full CWG group and a lot of meeting has been in subgroup meetings too. This includes that we've had a face-to-face meeting in Frankfurt in Germany in November. And we will have - we'll have two sessions during the ICANN 52 meeting. One is on Wednesday, the 11th and there is a Q&A session on Thursday, the 12th of February.
So the subgroups are actually organized in the same structure upon the structure of the ICG request for proposal. So and every group has a coordinator that's sharing the subgroup and it's a kind of a (unintelligible) in the CWG.
But as you can see, we have an RFP 1 with description of the community's use of the IANA function. It's completed. We have the RFP 2, which is the existing pre-transition arrangement policy sources. That is also completed. We have the RFP 3, which is a proposed post-transition oversight and accountability arrangement. This is ongoing.
The RFP 4 is the transition implication and that is ongoing too. And the RFP 5 is the validation of the NTIA requirements. This is on hold because we need to have RFP 3 and RFP 4 finished before you can evaluation if you are meeting the NTIA requirements. And the RFP 6 is a summary of the community process. That is also going to be - well, an assessment of how did we do it. Did we involve the community and so on?
So well, the original draft that was posted for public comment had the following main components. We had a contract call that holds the right to contract with the IANA functions operator. There was a proposal for a multi stakeholder review team. This is a team that should be responsible for making all the critical decisions and represent the multi stakeholder groups.
There was a Customer Standing Committee that's responsible for actually measuring the IANA performance. There was an Independent Appeals Panel that's supposed to make finding decisions for IANA on actions or inactions from IANA. There was the NTIA authorization function. And no recommendation is actually drafted in the transition proposal.
So this was the model that was sent out for public comment. And we received 48 contributions on this. And those gave the CWG the following input. One of the first input was there is strong support for the current IANA operations operator and within ICANN. And that the IANA function should not be removed from ICANN or tender it.
There was a strong support for the transition should not take place prior to the adoption of required accountability mechanisms that's being developed by the CCWG or at least this should be guaranteed to be adopted in a timely manner for this - for the CWG proposal.
There should be a Customer Standing Committee. And there was support for an Independent Appeals Panel that can make finding decisions regarding IANA actions or inactions.
And also there was a feeling that the proposal as a whole were too complex. The proposal didn't provide enough details for the different stakeholders to decide on and properly evaluate the actual proposal. So more details were requested.
So the CWG after the public comments the co-Chairs and the coordinators sent out the survey to the CWG in order to get any directions on which areas there were convergence and divergence on the original solutions. And furthermore, during the public comments period, the CWG has received a lot of - not a lot but they have received some proposals and suggestions. The CWG asked questions on if they had support or not from the groups.
So the CWG had this intensive work weekend in January and used this in order to analyze the survey, the public comments. And the result of this was that we concluded that given the result of the public consultations an alternative solution that included ICANN internal type solutions should be tried to develop within the group as an aside to - on the side of the (Contract Co) - the original solution.
There was also some key issues that needed to be solved and we needed independent legal advice in order to properly resolve key issues related to (Contract Co) and ICANN internal solutions.
So there was a feeling within the group that in order to actually assess the two proposals we needed more - or not more. We needed independent legal advice. Furthermore, in this alignment of the IANA CWG and the accountability CWG created, submitted issues for both groups.
And because of those issues, well, it became clear that it was almost impossible to meet the original target date of delivering the proposals for the chartering organization and the ICG by January 13 of 2015.
So the CWG, well, thought it was proper to take care of those issues and in order to do so, the CWG established a new subgroup called RFP 3b in order to discuss and develop ICANN internal options.
Furthermore, the CWG has developed a list of legal questions related to both options and are in the process of obtaining independent legal advice on these. A client committee has been created that's taking care of this.
A revised timeline that has been coordinated with the CCWG and communicated with the ICG has been developed by the CWG. And this new timeline is based on a best-case scenario. We found it was best to, well, go for the best-case scenario and aim to deliver a proposal to the ICG by the end - by June 2015.
We know there is a lot of dependencies and risks that needs to be taken into account and need to be minimized as far as possible. And of course we need to obtain legal advice as shown in the timeline. I'll show you the timeline in the next slide.
Well, we need to be sure to reach consensus within the community on a proposal as shown in the timeline. Furthermore, we're putting pressure on the chartering organizations since we hope they're able to approve the proposal in 21 days.
So if you see the timeline, I know it's not very easy to see and I don't know if I can make it a little bigger. Might help a little. But as you see, the timeline shows where we are trying to get on the different RFPs. And the triangles are the risk factors that we hope to keep under control and (minimalize) as far as possible.
Furthermore, the round dots are meetings we're having that's - that are ICANN meetings. And the others are maybe an intensive work weekend and a face-to-face meeting.
So we're trying to work towards this very optimistic but also a timeline that we will need to work hard on to reach. But we're confident that we will do our best to reach this and we really hope that we're able to make this. We know there are risks and we will keep an eye on those and try to keep them (minimalized).
Well, the - oh, I need to make this smaller again. Sorry. Well, furthermore, we have improved and further extended the coordination of the work of the CWG and the work of the CCWG accountability group in particular for Workstream 1.
And we're doing this by having weekly calls between the co-Chairs of the CWG and the CCWG. And we think it's very important to have this coordination and linkage to this group.
The next slide is actually showing the linkage and the process of how the proposal from the CWG goes to the chartering organizations and the ICG. And at the same time we have on the right side the process with the CCWG.
I will not go into details with this. But also urge you to have a look at this yourself and ask questions or do that during the Singapore meeting if you have any concerns about this.
Well, finally, the CWG has prepared a discussion document prior to the ICANN meeting and I will give you a short overview of what this discussion document contains.
But we hope this is - this discussion document has the purpose of, of course, to inform the community of the work that has been undertaken and the progress to date. But more importantly, this is actually to seek the input from the community on key issues in order to assist us in our further deliberations.
So we have tried to make a document that's not too long, that gives a short overview. It doesn't contain a lot of details. But it contains enough details to get a sense of the different models. And furthermore, the document will also have some questions for the community to - so we can get some responses on areas that we're keen on getting input.
What are the models under discussion? Well, we have two models. We have the internal versus the external model or option. And those two are having a fundamental difference in who replaces NTIA as the body responsible for overseeing the performance of the IANA function.
The external, well, has a replacement of - replacement entity that cannot be ICANN but ICANN would be granted to the contract for the IANA functions post-transition of this entity.
The internal is NTIA would transition its functions including right to determine who performs the IANA function to IANA, which would continue to operate the IANA functions without a contract subject to the community's ultimate right to require ICANN to transfer the authority and the IANA functions to another operator.
And this is a common feature for both; the separability, the rise from the principles of the CWG. And this is also a very important and has been raised by many of - and it's a principle of the CWG.
Well, both models the internal versus the external model has some comment points. And I'd like to highlight those. Well, one is a kind of a multi stakeholder review team. Well this is meant as a group of stakeholder that is representatives responsible for completing the new IANA functions definition.
We have the Customer Standing Committee that's going to be a smaller group of individuals that is responsible for overseeing the performance of IANA. There is the Independent Appeals Panel that is - will have all decisions or actions from IANA would be subject to independent and binding appeals mechanisms.
And there is equally important separability where the IANA functions would not be transferred from ICANN at the beginning of the transition but MRT, the Multi Stakeholder Review Team could only initiate the mechanisms for separation of the IANA functions if ICANN breach the IANA functions agreement or fail secure that breach.
So both the external and internal models include mechanisms to ensure that the IANA functions can be separated if necessary. But how this is done vary between the models.
So if we take a look at the external model, we have the (Contract Co) where the multi stakeholder community establish a non-profit corporation. That assures NTIA IANA functions responsibility.
Well, the (Contract Co) should be a small lightweight company whose main responsibility is holding the contract regarding the IANA functions. And if ICANN (unintelligible) should breach or fail secure a breach, well, the (Contract Co) could select a new operator.
But because (Contract Co) is a legal entity would be able to enforce the agreement against ICANN. And the MRT is likely to be a committee of (Contract Co) and would be responsible for providing instructions to the (Contract Co).
This CC would be similar as described before but likely to be a committee also of the (Contract Co). And the IAP is the general appeals panel is as described before.
There is another external model and that's external trust model where the (Contract Co) instead of taking form of a company would take form of a trust established under U.S. law. The trust would have a Board of Trustees, which would likely be incorporated as legal entity. And trustees would be selected from the multi stakeholder community.
This trust would receive an assignment from NTIA with all of the U.S. Government's rights and duties included within its stewardship role. And the trust primary purpose and duty would be to select and contract an IANA functions operator contract.
The IANA functions operator would be on the contracts for (a chain) of years. And well, subject to terminate if for a cause or other necessary or appropriate terms and conditions. And the MRT, CSC and IAP the multi stakeholder review team, the Customer Standing Committee and the Independent Appeals Panel would be the same.
Well, as we said, there are internal models and those are also divided into where one is an ICANN internal bylaw model where NTIA would transfer the rights from the contracting IANA functions to ICANN but only after it has amended its bylaws to create a golden bylaw. That's a bylaw that cannot be unilaterally amended by the ICANN Board.
The golden bylaw would guarantee that ICANN would not relinquish the right to perform the IANA functions to a third party if required to do so by a multi stakeholder review team.
Well, a separation of IANA could possibly require the creation of a (Contract Co) or a trust. Well, MRT additional bylaw modification would create a standing committee in ICANN to be the MRT. And the CSC would similar be described before but would be merged with the MRT to varying degrees depending on the actual requirements. And regarding the Independent Appeals Panel, additional bylaw modification is needed to specify the IAP procedures.
There is also a model that contains an internal trust model. And here is the transition from the NTIA would require ICANN to enter into a declaration of trust to hold the right to the IANA function and trust for and perform the names IANA functions for the benefit of the multi stakeholder community.
Well, the declaration of the trust itself does not necessarily create a separate company but we would be a legally valid instrument. There would be a guardian or protector of a pointer of the trust, which would be a cross community group similar to the MRT.
The guardian would have the authority to initiate an escalation process but it cannot decide to execute the transfer. Action would only be taken with input agreement from the multi stakeholder community through pre-defined processes.
The MRT/guardian, well, the declaration of trust would codify the membership, responsibilities and operating procedures of the MRT. And the Customer Standing Committee similar as described before - Standing Committee, which perform strictly operational and administrative role. Well, and regarding the Independent Appeals Panel additional bylaws as needed to specify the procedures.
So this was a quick overview of the two models and of the four variations of the two models. Furthermore, we are having questions for the community. This is work in progress. We hope to send out the discussion document very soon including the questions for the communities.
And, well, we hope that you will all get involved in the discussions we are having. Apart from those Webinars we're having a working session on Wednesday, 11th of February. We're having the CWG Q&A session on Thursday. And if you're in Singapore, it would be nice to see you at any of those sessions. If not, you can join in by listening and responding in Adobe.
So we are really hoping to get as much feedback on this as possible. You're also welcome to post any comments to the list we're having. So we're trying to reach out and get as much involvement in this by having this discussion document that is short and hopefully comprehensible and easy to get a quick overview and so we can get some directions of where the community are on these issues.
So I see a question. It was mentioned that the best-case scenario for the CWG in order to present its proposal to the ICG in June. What if this deadline cannot be met? In order for the very strict timeline to be fulfilled, the deadline of June must be met because the AOC finishes at the end of September. What happens if the deadline cannot be met or that ICG will not conclude to a final commonly acceptable proposal?
Will the working groups have more time to improve their proposal? And what happens if the NTIA does not like a proposal? Does the U.S. Congress play a significant role in the whole IANA Stewardship transition process? Can the Congress postpone the process and create any other obstacles? Question mark.
Well, to the first question if we don't meet the deadline, I - which we hope we will, it has been said that there is a possible extension of the IANA contract with the entire NTIA. But we're not aiming for this. We're aiming for meeting the deadline and we hope to do so.
Regarding if the ICG will not conclude on the final proposal, it will have to go back to the group and we have to do more work. There is a period where the ICG can question - can send questions to the CWG. And we hope that these are sorted out along the way because we're - a lot of people are following both groups. So there is cooperation between the ICG and the CWG. Not on the actual content but we know a lot of people are participating in both groups.
Regarding the AOC, I see Pat Kane mentioned that it doesn't have a termination date and that's true. But the actual IANA contract has a termination date.
I must say you posted a question regarding the U.S. Congress. It is not in the scope that they're playing any significant role. But I'm not - I don't know enough about U.S. politics to say anything about their possibility of interfering with this process I would say.
But as I said, the best-case scenario is actually what we're trying to meet and we're confident that if we all try to do our best and if we get the legal advice and if we find consensus, this will not be too hard to accomplish.
Is there any other questions? Let's see. What if the NTIA doesn't like the proposal? I think if we have a proposal that's in any way my view - if we have a proposal that's agreed upon by ICANN Board, by all the chartering organizations, by the - well, the multi stakeholder community as a whole, I think it would be very difficult to turn down any proposal.
But that is also one of the main requirements from the NTIA that they want a proposal that has consensus among the multi stakeholders. So I see the - Olivier Crépin-LeBlond says NTIA has said that they will ask the community to amend their proposal accordingly.
Yes. So and I see Cheryl. Not sure I agree. I see NTIA holding the trump card here. Yes. Yes. But I guess if you meet the requirements, I - well, I don't see it will have a good reason to turn down a proposal. And I think the requirements from the NTIA are pretty straightforward, but.
Okay. What is the meaning of the trump card here? Sorry. It's all Greek to me. Well the trump card to me is they can - they have the higher stake. They can decide.
So (Matthew) says NTIA expects the community to have put in place and committed to a certain set of accountability enhancement at ICANN as part of the transition. Yes. That is true.
Okay. I think those questions are very hard to answer. But I hope I answered them as you - I give you that you asked for and I don't know if there's any other questions.
There's someone typing so I'm waiting. Oh, thank you. Is there any other questions? It doesn't seem so. But I see someone is not going to be there in Singapore but I hope you have the - have time to listen in and participate online anyway.
Okay. And if there is no other questions, I will end this session and say thank you very much for joining me. And I hope to see many of you in Singapore. And if not, I hope you will join remotely and provide input on this very important issue.
Thank you and have a nice day, morning, evening, afternoon, wherever you are. It's late evening in Denmark. So I will go to sleep now. Okay. Bye.