Moderator: Gisella Gruber-White
February 3, 2015
8:00 am CT
Coordinator: The recordings have been started. Please proceed.
Grace Abuhamad: Thank you. Welcome to the first CWG Stewardship webinar. It's 14:00 UTC. Your presenter today will be one of the co-chairs, Jonathan Robinson. Jonathan, over to you.
Jonathan Robinson: Thank you, Grace. We've taken this opportunity to present the - an update of the work of the Cross-Community Working Group on naming-related functions to the community ahead of the ICANN meeting which is due to take place formally commencing Monday next week in Singapore, although some preliminary meetings will be taking in advance in place, so the Monday opening session.
So let me go straight onto the first slide which attempts to set the context. And there's a series of context-setting slides in the background that we'll work through. We take you back, and many of you will be familiar with this, and we aren't going to go into a lot of detail in these first few slides. But really the purpose of these slides is to put on record a clear background as to how we got to the work of the CWG being developed and how it fits into the broader context of the so-called transition of stewardship of the IANA functions.
So the process begins back in March 2014. The U.S. government's announcement of its willingness and intent to transition the stewardship of the IANA functions to the global state - the global multi-stakeholder community, and in so doing, asked ICANN to convene global stakeholders and in that sense serve as a facilitator based on its current role as IANA functions administrator and as global coordinator of the Internet domain name system.
The NTIA, as many of you all know, set out some key transition requirements, and that includes the requirement to -- I apologize if there is any visual problem with the slide, I'm certainly seeing a little bit of overlap in the presentation here -- but essentially to support and enhance the multi-stakeholder model, maintain the security, stability and resilience of the Internet DNS, meet the needs and expectations of global customers and partners of the IANA service, and maintain the openness of the Internet.
And in particular, the NTIA specified that it will not accept a proposal that replaces the NTIA role with a government-led or intergovernmental solution.
So this next slide doesn't resolve well on the - in the presentation room, but in essence this described in detail the IANA functions and will be available for you as part of the presentation.
So to be clear, we will circulate this and we'll make this presentation available for this form of detail. But essentially, IANA deals with a set of functions that cover so-called numbers, protocols and domain names. For purpose of this webinar, it's to really deal with the work of the cross-community working group dealing with domain names or naming-related functions.
So at a very high level, the stewardship transition is being handled by - in a number of different ways. There is a coordinating group which is bringing together the proposals from the domain names community, and that's the work of this CWG, in addition to the proposals from the numbering resources community and the protocol perimeters community.
One of the critical points is that this is being linked because of the historic overarching oversight function that the NTIA performed with respect to ICANN and IANA, it was argued and broadly accepted that there was a requirement to link any practical work done on the transition associated with names, numbers and protocol perimeters together with an additional stream of work, which dealt with any issues or concerns over enhancing ICANN accountability.
So there is a separate but related and connected group working on enhancing ICANN accountability.
I will just pause for a moment and check that you are hearing me loud and clear. You don't need to all respond. I will just check with Grace from ICANN staff if you're still getting clear enough audio, because I see there is a comment from one participant indicating that they have problems with audio. Grace, can you just confirm to me that you are still hearing me okay?
Grace Abuhamad: Yes, Jonathan. We can still hear you fine. I'll work with participants to help them individually if there's still issues.
Jonathan Robinson: Thank you very much. All right. So moving on through this at a reasonable pace through this introductory work. And the reason for doing is because with substance I'm sure or what you want to hear is about the work of the CWG most recently and where we plan to go, but nevertheless we felt that both for the purposes of this webinar and for the record within the slide deck itself, it would be useful to have more comprehensive background.
So the final process elements that take place were to establish the coordination group, or what has become known as the ICG, which will have representation from all stakeholders, and the community self-selects the members of that and according to the other key perimeters such as establishing its own working methods.
And then, in addition to that, ICANN's role is to serve as the convener and facilitator of the process, remaining neutral throughout but working such as the facilitation and support for the webinar to assist with engagement, outreach and other relevant support to the process.
The ICG as its - the ICG has its key set of tasks: to act as liaison to all interested parties, to make sure it assesses the outputs of the three operational communities, and in particular (unintelligible) compatibility and interoperability.
And so one of the challenges here will be to make sure that the three distinct proposals being fed into the request for proposals from the ICG are indeed - can be knitted together, if you like, that they can form a coherent - can be brought together into a formal, a coherent single proposal. And that of course is the fourth task: assembling and completing a complete proposal for the transition, and throughout that process for making sure that information is well shared and handled.
The ICG put out a request for proposal, which I touched on a moment ago, and created some key... Thank you. If you could just make sure that if you have the opportunity all microphones are on mute. The ICG broke its request for proposal into five key components, seeking input on the use of the IANA functions, a description of the function, the existing arrangements, the proposed arrangements, and the implications of those proposals.
And indeed as you'll see, the CWG, whose work we report on here, chose to structure both its work and its draft proposal along those five components of the RFP.
Let's reiterate the fact that their proposals come in from three different groups, and this gives you a graphical representation of how those different groups are made up and submitting their separate individual proposals and responses to the RFP to the CWG.
So the discussions have taken place and the proposals have been worked on, and the request from the ICG was that the three different communities should deliver their proposals to the ICG on the 15th of January. The CWG, which is the dark blue column on the left and whose progress we report on here, began its work.
And all that work is publically archived and available over a mailing list, broke down the work into subgroups dealing with the different sections of the RFP as prepared by the ICG, and then posted an initial draft proposal for public comment from the 1st to the 22nd of December.
Now those of you who will be familiar with the multi-stakeholder process, and in fact any complex multifaceted process, will recognize that the group has worked with some speed, especially considering it’s a diverse and international group. And to assist that speed of working, we held an intensive work weekend during the 10th and 11th of January which really tried to focus on how the CWG was going to deal with and respond to public comment in the main.
We used some tools to do that. I'll touch on that some more in a moment. But suffice it to say there was both a speedy initiation to the work, continued work through the traditional December/January holiday season, and then onwards into January with the weekend of work.
So let's talk about now the sort of output that have begun to be produced there and some of the substance. First of all it's worth understanding what the makeup of the Cross-Community Working Group. There're around a little over 130 people involved, of which 19 are members. The way in which this works is there are chartering organizations who supported the charter, the work description if you like, for the working group, and each of those chartering organizations had the opportunity to nominate members to the group.
In addition to those nominated or proposed members of the group, there are over 100 participants. To date, there is no discernible difference from the contribution and participation of the members and participants, save for the fact that the members were sponsored to travel to a face-to-face meeting and their travel costs were met in November last year. Other than that, the participation's been equivalent, and indeed the participants, if they were able to support their own travel, were able to participant in the face-to-face meeting in Frankfurt.
We're going now, as I said at the outset, into the ICANN 52 meeting in Singapore, and we intend to have additional working sessions during that. And these will essentially be similar to those that we've been holding on a weekly basis in addition to the subgroup meetings. So this group has met more or less every week since the group was commissioned in the - around October last year, since we began to work in earnest.
There are five subgroups, as I said, but I'll respond in particular to the different, well, variations or components of the request for proposals from the ICG. They're described at the bottom of Slide 13. Really the substantial work, as you can expect, is in and around RFP3 and 4. That is to say what the proposal is, proposed transition oversight and accountability, and what the implications of that proposal are, as dealt with by RFP4.
The draft proposal at this stage coming out of Frankfurt at least in the early part of December, had five key components that are perhaps worth highlighting. The first in green, marked number one, was the concept of a contracting company. The idea being that, at present, ICANN has - operates the IANA functions and a contract with the NTIA. So assuming, and you may not agree with that assumption, that there is a requirement for an entity with which ICANN has to contract, a contracting company was proposed.
In addition, there was the proposal for a multi-stakeholder review team which had ultimate oversight of the contracting company. In addition, item three, lower left in orange, a customer standing committee responsible for monitoring and managing the day-to-day operational performance. It was expecting that that customer standing committee would be made up entirely or mostly of customers of the IANA function, typically registries.
In addition, an independent appeals panel in order to deal with binding appeals for particular IANA actions or inactions in response to instructions given to IANA. And finally, there was the recognition that NTIA performs an ultimate authorization function. And in the first instance, the draft transition proposal did not contain any recommendations in this regard.
So having created that draft proposal in Slide 15, we then went onto take detailed public comments and noted many things, which this slide attempts to capture the most salient points of. There was certainly recognition that at present the IANA functions should not be moved from ICANN or tended for at the onset of the transition on the basis that's probably two-fold.
One, they were currently being performed adequately, and two, it was the potential creation of an unnecessarily unstable situation, especially given that they were currently being performed satisfactorily. Second, that the transition should not take place prior to either the adoption of specific required accountability mechanisms or at least the guarantee that such mechanisms would be adopted in a timely manner in the future.
There was pretty widespread support for the customer-standing committee, in other words recognizing the need for customers to have - customers of the IANA function to have adequate and effective representation. There was recognition that there should be an independent appeals panel and support for that that can make binding decisions regarding the IANA actions or inactions.
And there was some feedback which was, in a sense, slightly contradictory that the whole proposal was potentially too complex, reflecting the fact that in many people's view, the IANA functions is fundamentally a relatively simple function to perform, and slightly contradictory, as I said, that the proposal did not provide enough details to properly evaluate it, and also some comment that the time to comment was too short. Now that's a challenge for the CWG for that comment period and is likely to be in the future.
It's a consequence of an overarching objective to deal with the work in a timely fashion and in particular as (unintelligible) to attempt to be - provide the proposal near or close to the 15th of January. But notwithstanding that, in any event, there is a recognition that this work needs to be done at a reasonable pace, and one of the consequences of that is a consideration for what might be considered reduced or unconventionally short public comment periods. In this case, around 20, 21 days.
So during the course of the intensive work weekend, the public comments were integrated. And in addition, the working group was surveyed in order to try and collate responses to and assess for support for the comments and proposals received. And really four critical points came out of that.
One, that the contracting company was beginning to be referred to as an external-to-ICANN solution. In other words, ICANN was contracting with entity outside of its own bylaws, if you like, and outside of its own corporate umbrella. But that's an adequate description of it.
But essentially that there was - further consideration should be given to mechanisms whereby the replacement for the contract of NTIA was with a form of internal-to-ICANN solution, which is short hand in some ways for a modification of ICANN's legal or other structures in order to accommodate the absorption of the IANA function.
There was a significant recognition that regardless of whether it was an external contract co type solution or internal solution, it was going to be very challenging for the group to adequately resolve all of the issues around the solutions without well qualified legal advice and input.
There was also a recognition that the so-called interrelated and interconnected accountability work needed to be accurately, well effectively, coordinated, and the initial misalignment and different start times of the two group's work had meant that - a slower start, a less productive start for the collective work than might ideally have taken place.
And ultimately the recognition that the - meeting the ICG's target of the 15th of January - well objective for responses to the request for proposal, the 15th of January, which this group had always would be - it could only meet on the 30th of January, was no longer a viable proposition, and that timescale would slip.
So this slide says Activity to Date, but really what this slide and its set of four or five successors - successor slide aim to do is cover the recent work, the post-intensive work weekend of the ICG - of the CWG group we're reporting on here.
So what the CWG did next was to begin to develop a discussion and the - flesh out prospective proposals on these so-called ICANN internal option or options and to establish a further subgroup or which is arguably part of a section of the work under RFP3 and was therefore known as RFP3B to actively consider and develop further the concepts of an internal to ICANN proposal.
In addition to develop a basis for legal questions and advice related to both primary options under consideration and to move ahead towards obtaining legal advice on these options.
In addition as you see in blue in the middle of the slide a revised timeline for the delivery of the transition work and in particular a revised timeline that was coordinated with the work going on in accountability and effectively communicated to the ICG since they are waiting for the proposal input from the CWG.
Having said that they are waiting it is our understanding that they are not unable to continue working as a process and begin to evaluate the input from the numbering and protocol groups the proposals.
But nevertheless they are keen to receive as soon as reasonably possible a proposal from the CWG.
So as we worked out on the timeline and spent some detail doing it we looked at a number of different scenarios best case, base case, and worst-case.
And after some careful discussion agreed to publish and communicate our best case scenario whilst at the same time making it clear to all reading that best case scenario that it was by definition a best case scenario and dependent on our ability to mitigate and minimize some key risks three of which are highlighted on this slide.
And that is to say the timely provision and acquisition of legal advice, the ability and to some extent willingness of the community incapacity to come to together in a consensus around a variant of one of the current proposals in discussion and then significantly for that variant around which the consensus is achieved to be reviewed and approved by the chartering supporting (organ) events and advisory committees.
That timeline is published here. For completeness I realize it’s not particularly legit here but the salient points are that it recognizes the requirement to continue with the different subgroups of work.
It recognizes the requirements to have legal advice and input. It recognizes that that legal advice and some other key components referenced by triangles on the slide are areas of risk.
And it recognizes that in order to meet this best case or aggressive timetable a short, a further public comment period should that be required which it almost certainly will have to be a similarly short period for which the CWG received at least some negative feedback.
So there are a number of factors in here that need to be highlighted. But if everything works according to plan and we do manage to work to this best case timetable it is expected that we can deliver a final proposal at or around the June ICANN meeting.
So additional work that’s taken place over and above the development of the internal options, processing legal questions, the revised timeline is to improve and further develop the work with the CCWG on accountability in order to ensure that their work which is divided into two separate streams and stream one of those two separate streams is the work that is directly linked to the work of this group and that that is properly and in an effectively coordinated fashion linked to our work.
So that’s been a crucial piece of work that’s been ongoing. And here we have a graphical representation in slide - in the current slide which shows the interrelationship between the two groups.
I don’t expect you to be able to decipher this now. It’s available for as part of the comprehensive slide pack.
But suffice it to say for the moment that it shows that the proposal from the CWG to the ICG will be contingent on adequate and appropriate accountability measures being developed in a timely fashion in Workstream 1 and appropriately coordinated with the work of the CWG.
Myself and my co0chair in this group are Lisa Fuhr are in close contact with the three co-chairs of the CCWG and have every confidence at this stage we will be able to work together with that group to make sure with the support of the liaisons and other elements of coordination that the work is appropriately and adequately coordinated.
So that really gets up to where we are now. And that’s the publication of a discussion document. We felt as a CWG that we were not in a position to publish a revised draft at this stage.
The proposal if it were to be called a proposal at this stage is bifurcated or split into - in too many ways at the moment.
It needs further work before it can be brought together in and around the way in which we have or believe we have consensus.
So the objective here is to present the key areas of divergence and indeed convergence within the group to the community at large during the course of the Singapore meeting and obtain feedback on key areas and issues during the course of meeting such that emerging from Singapore we are in a much better position we hope to be able to move forward to a converging and ultimately consensus proposal.
So there you have it. The discussion the purpose of the discussion document for which this Webinar is a precursor is to inform the community of the work undertaken in particular background, work to date and progress made so far and then to seek community input on the key issues that we face and in particular on various particularly challenging areas in order to assist the working group in its deliberations.
So to sort of bring this to a head and give you a feel for where really the substantive points around which there are key areas of discussion it’s worth highlighting briefly what are effectively four interrelated or four models that under discussion some of which have areas of overlap, all of which have some areas of overlap but some of which have quite significant areas of difference.
So we’ve talked about the fact that they are potentially external and internal. And interestingly though there is a common feature which is ultimately derived from the principles of this Cross Community Working Group, this CWG and that is that ultimately eventually should there be an irreconcilable or irretrievable issue with the performance of the IANA functions there may be an ultimate need to separate out those functions in the future from ICANN.
The question is how might that be done and in what vehicle do those functions sit? So under the external model the replacement entity could not be ICANN but ICANN would be granted a contract for the IANA functions.
Under the internal model the IANA functions remain with ICANN and ICANN continues to operate the IANA functions but subject to the communities’ ultimate right to require a transfer of those functions should they be operated in sustainably in an unsatisfactory way.
So there are many common points and these attempt to highlight them. I’ve touched on all of them before. The Multi-stakeholder Review Team, the Customer Standing Committee, the Independent Appeals Panel and the ultimate concept of separability.
But when you dig in a little bit more detail it’s worth having a look at some of the key points around the both external and internal models as follows.
First the external models, we talked about Contract Co earlier and the concept of the community establishing a corporation which would be small and lightweight and it would become an entity with which ICANN could contract for the IANA - for the running of the IANA funds.
And ultimately should that - should ICANN materially breach that contract and fail to cure such a breach the Contract Co could select a new operator.
And the concept behind the Contract Co becoming being a legal entity is its ability to enforce such an agreement against ICANN.
The Multi-stakeholder Review Team would be some form of committee with oversight and the customer service committee similar to as described before and similarly with the Independent Appeals Panel.
Ultimately the MRT would have the authority to issue instructions to the contract company.
A variation has been proposed in the form of a trust so-called external trust model. And here the Contract Co would no longer be a contracting company but a trust established under US or other law.
The trust would have a board of trustees and the trustees would be selected from the multi-stakeholder community.
And there are very subtle differences as to how the functions would be embodied within the trust but the trust’s primary purpose and duty would be to select a contract for the IANA functions operator if indeed that is ever needed to be an operator other than ICANN.
And you’ll see on the bottom bullet point that the MRT Multi-stakeholder Review Team Customer Standing Committee and IAP could be the same as under the contract company model or a variation of that with some part potentially moved internally to ICANN.
Then the so-called internal models, first the internal bylaw model and in under these circumstances there would be some form of variation to the ICANN bylaws such that although the IANA functions would be held within ICANN post transition to NTIA there would be a bylaw that could not be unilaterally amended by the board that could ultimately be involved to create a perspective separation of the IANA function in the event that there was material and remedied breach of the performance of the IANA functions which (unintelligible) the IANA functions.
Just waiting for that echo to go, thank you. The MRT and CSC would have - are still variations of the same in this model and have the form of commonality but would be necessarily created within and under the bylaws of ICANN and the independent appeals panel which similarly require modifications in order to provide for the scope and remit of the independent appeals panel.
Finally a variation of the trust model where there was a form of - where there is supposed to be a form of internal trust where ICANN would enter into a declaration of trust to hold the right to the IANA function in trust for and perform the function for the benefit of the multi-stakeholder community by identified mechanisms.
Whilst the declaration of trust doesn’t necessarily require the creation of a separate company as in the case of the likes of a Contract Co it would still be a legally valid instrument.
And then there are a variety of details including the concept of a guardian of the trust being a cross community group similar to the MRT and the sort of custodian of that function.
And in addition scope for a CSC has before and an independent appeals panel again that’s some form of modification of the bylaws.
You’ll note that there is the capability to initiate an escalation process should there be inadequate performance and ultimately the prospects of as a last resort separation through some form of predefined process.
So having done this work and got to a point where there are a number of variants in the proposal which I’ve gone through both the background in detail, the mechanics of how we got there and the current position of the group there is a clear requirement to propagate this information out into the broader community beyond the CWG and take serious soundings as to what is tolerable, acceptable, substantially problematic and in particular to frame some detailed questions that try to better understand community responses to these points.
And so that is really the work in progress is to - as questions are part developed and will be released with the final version of the discussion document and we will use those as a basis to facilitate the discussions in Singapore.
You of course are welcome to the extent that you are able to travel to Singapore or plan to be there in any event or via the numerous mechanisms for remote participation. And here we highlight where we’ll be having both today’s Webinars, both of them, one again later today presented by my co-chair in addition the working sessions in Singapore and the Q&A sessions and various others that will deal with either the transition, the work on accountability, the work of the ICG and all of the related activities.
So thank you very much for listening and participating. It’s - we felt it was very important to get this information out. And you clearly did appreciate the opportunity by virtue of the fact that you’ve attended the Webinar.
So let me pause now and make sure that we are in a position to take any feedback or questions. But, thank you for paying us the attention that you have and we will look forward to continuing to work with you.
Grace Abuhamad: Thank you Jonathan. This is Grace Abuhamad. So to - if any of you have questions that you would like to ask on audio feel free to raise your hand and we’ll start a queue.
If you have a question and you’re not able to pose it on audio but you’d like it to be read out loud you can put that into the chat.
I’ve put some instructions just on to make sure that we know what part of the chat and what’s an actual question for the chair. So if you need any assistance with that we can help you out in the chat.
Jonathan Robinson: There is another point Grace. And that is to the extent that this is made one or more participants think of questions that should be being tested in the community during the ICANN Singapore meeting we are receptive to hearing those as well.
Well thank you for your complementary comment in the chat. We appreciate that. There has been some tremendous work on the part of the CWG to do the work.
Significant hours I’m sure beyond, over and beyond those contracted by ICANN support staff. And so it’s been a big effort to get to this point.
And I know there are some frustrations that we aren’t further without proposal but it is necessarily a condition of this kind of work that one has to give it the time to percolate through properly and be dealt with in a thorough way thus that by the time we try and bring it together in a form of convergence and consensus that everyone feels at the very least that they’ve had their say if not that the proposal actually represents some form of ideal or satisfactory compromise position.
All right well it looks like we - this was primarily the primary objective of this was to be able to communicate the current position.
We very much look forward to talking with you in Singapore via the various sessions and the relevant chordal conversations.
Thank you again for attending and I think we’ll bring this to a close at this point then Grace.
Grace Abuhamad: Thank you all for joining. The meeting is now over.