December 2015 - Accountability-Cross-Community

Work plan in January/Meeting schedule
by Brenda Brewer Dec. 27, 2015

Dec. 27, 2015

Holiday Greetings to all! Please find the January schedule of meetings below and also attached in pdf. Calendar invites soon to follow. You may also look at the CCWG Accountability Meetings Calendar wiki page here: https://community.icann.org/x/ogDxAg (located bottom of wiki page) 2016 January CCWG ACCT Meeting Schedule (subject to updates) Tuesday Calls Thursday Calls 5 Jan 19:00-22:00 UTC 7 Jan 19:00-22:00 UTC 12 Jan 06:00-09:00 UTC 14 Jan 06:00-09:00 UTC 19 Jan 12:00-15:00 UTC 21 Jan 12:00-15:00 UTC 26 Jan 19:00-22:00 UTC 28 Jan 19:00-22:00 UTC Kind regards, Brenda From: accountability-cross-community-bounces(a)icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Mathieu Weill Sent: Thursday, December 24, 2015 5:22 AM To: 'Accountability Cross Community' <accountability-cross-community(a)icann.org> Subject: [CCWG-ACCT] Work plan in January Dear Colleagues, In line with the work plan discussion held on call #72, we wish to inform you that we have decided to increase the number of calls per week to two to allow for an in-depth analysis of the input received on our Draft Proposal, and discuss any complex requests for change there may be. It is currently foreseen that this frequency of calls will only apply to the month of January. As discussed on 22 December, these calls will be plenary and topic-based. You will receive a list of topics in advance of the meetings so that you may plan your participation accordingly. Duration of the calls will also be extended to 3 hours to allow for ample time to complete our tasks. Calls will be cancelled (and/or duration will be reduced) if deemed unnecessary. Please note that staff will send invites as well as overview of the conference call calendar shortly. We look forward to reconvening in January and wish you a happy holiday season for those of you who celebrate. Best regards Mathieu Thomas - León

8 13

Fwd: FW: ICANN Board Comments on Third CCWG-Accountability Draft Proposal on Work Stream 1 Recommendations
by Jordan Carter Dec. 26, 2015

Dec. 26, 2015

---------- Forwarded message ---------- From: *Jonathan Robinson* <jrobinson(a)afilias.info> Date: Monday, 14 December 2015 Subject: [CWG-Stewardship] FW: ICANN Board Comments on Third CCWG-Accountability Draft Proposal on Work Stream 1 Recommendations To: cwg-stewardship(a)icann.org All FYI *From:* Michelle Bright [mailto:michelle.bright@icann.org <javascript:_e(%7B%7D,'cvml','michelle.bright(a)icann.org');>] *Sent:* 14 December 2015 06:17 *Subject:* ICANN Board Comments on Third CCWG-Accountability Draft Proposal on Work Stream 1 Recommendations Attached, please find the ICANN Board Comments on Third CCWG-Accountability Draft Proposal on Work Stream 1 Recommendations. Kind Regards, Michelle Bright Michelle Bright Board Operations Content Manager, ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 Direct: +1-310-578-8678 Mobile: +1-310-570-8296 http://icann.org -- Jordan Carter Chief Executive, InternetNZ +64-21-442-649 | jordan(a)internetnz.net.nz Sent on the run, apologies for brevity

25 77

Our timetable -- some personal observations
by Jordan Carter Dec. 25, 2015

Dec. 25, 2015

Hi all I would like to put on record my personal observations regarding the schedule of our work for the past few months. I do so in an effort to be as transparent as possible about my own role in the process, and to offer some thoughts on the consequences of further delays at this point. First, I believe we have pulled together a credible Third Draft report which can be accepted as is by the SOs and ACs, and would pass the NTIA tests. So the fundamental quality of the work is not in question. Second, what will be vital (given the short timeframe for this Third Draft and the limited public comment) is that there is fulsome and non-truncated public comment on the Bylaws and other changes that will give effect to these proposals. That is where the "Every Word Has To Be Right" standard must be applied. For the current report, the intent must be clear - and that is the basis on which I have been happy to accept the truncated process for this phase. Third, the drivers. To me the following have helped leave me able to deal with the compressed timeframe: - pressure from senior ICANN staff and directors to "get it done" - and clear paintings, as recently as Dublin, of "horror" scenarios if the report isn't finished by mid-January. This has tended to be based on views about the U.S. political cycle. - pressure from the numbering and protocols communities, who want this done and dusted and wish the transition had already been done. - the desire generally to close the work out, given the slowly reducing levels of volunteer commitment evident over the past few months. So I have been able to live with that. Fourth, I want to note my own ongoing frustration with the way the ICANN Board has involved itself in this process: - non involvement in the first parts of the process - interventions in the second draft proposal consultation and, problematically, around the Los Angeles meeting that made it impossible for us to present a Third Draft Report to the Dublin meeting. - a new intervention now with further substantive changes proposed, some of which are fundamental to the Third Draft (esp. the human rights, voting thresholds, inspection rights and IANA budget) that cannot be incorporated without further delays to the process. - the astonishing change in tone about the timetable - from "THIS MUST BE DONE" to "we should take the time to get this right!". It seems to me the Board's conflict of interest in this process, which is inherent (the body being held to account is inserting itself into decisions about how that should happen), has been managed in a fashion that has made our work harder, that has called into question the ability to complete a workable proposal, and has caused unnecessary stress and friction both within the CCWG and with the other operational communities. That said: we are where we are. So for the next few weeks I offer this observation. If the substantive changes proposed by the Board on the items I noted above are agreed to by the CCWG, it will require: - diligent work to assure the quality of the proposals, including legal review - a re-presentation of the final proposal, along with explanation of why the changes have been made - a re-consideration of the final proposal by the chartering SOs and ACs. This will all take time, and in my view at least a month of time if not more. That is even if the outcome is not to agree with the Board's changes. (Personally I think a few of them are helpful, and that they should be judged on the merits - if we agree to take the time to do so.) ICANN agreeing to a slower timetable is one thing, but it does not change the fact that other actors do not wish to see more time taken. I cannot imagine numbers and protocols being happy about further time. (That is a deliberate understatement. I think they would be furious.) So in the end, the critical decision we face is whether to deal with substantive comment in a way that could lead to key things being changed in a manner that: - accepts fundamental changes and the change to the schedule involved - rejects fundamental changes, and takes the risk of the Board's comment it may oppose those changes coming true As usual, we are again in an invidious situation through no fault of our (the CCWG's) own. It is no surprise volunteer numbers are down. I would be interested in the views of other participants on the following: - do you think substantive changes such as those of the Board would require delays if adopted following the close of public comments? - do you feel comfortable with delay if required? best, Jordan -- Jordan Carter Chief Executive *InternetNZ* +64-4-495-2118 (office) | +64-21-442-649 (mob) Email: jordan(a)internetnz.net.nz Skype: jordancarter Web: www.internetnz.nz *A better world through a better Internet *

15 30

Re: [CCWG-ACCT] CCWG ACCT Meeting | 19:00 UTC | Thursday, 7 January
by Dr Eberhard W Lisse Dec. 24, 2015

Dec. 24, 2015

For the ones where I can't establish my availability right now, I will advise closer to the time. As we do not need to spend 6 hours per week on this, I'll see if and when I can make it. el On 2015-12-24 19:19 , Brenda Brewer wrote: > Hi Eberhard! > > Noted. Thank you. > > Brenda > > -----Original Message----- > From: Dr Eberhard W Lisse [mailto:el@lisse.NA] > Sent: Thursday, December 24, 2015 11:18 AM > To: Brenda Brewer <brenda.brewer(a)icann.org> > Cc: Lisse Eberhard <directors(a)omadhina.net>; accountability-cross-community(a)icann.org > Subject: Re: CCWG ACCT Meeting | 19:00 UTC | Thursday, 7 January > > I will be in transit. > > el > > On 2015-12-24 18:09 , Brenda Brewer wrote: >> *CCWG-Accountability Meeting*– Thursday, 7 January 2016 from 19:00 – >> 22:00 UTC > [...] >

1 0

Re: [CCWG-ACCT] CCWG ACCT Meeting | 12:00 UTC | Thursday, 21 January
by Dr Eberhard W Lisse Dec. 24, 2015

Dec. 24, 2015

I have to work for a living and can, perhaps, attend from 12:00 to 13:00 UTC. el On 2015-12-24 18:05 , Brenda Brewer wrote: > *CCWG-Accountability Meeting *– Thursday, 21 January 2016 from 12:00 – > 15:00 UTC [...]

1 0

Re: [CCWG-ACCT] CWG ACCT Meeting | 06:00 UTC | Thursday, 14 January
by Dr Eberhard W Lisse Dec. 24, 2015

Dec. 24, 2015

I will be in transit. el On 2015-12-24 18:07 , Brenda Brewer wrote: > *C**CWG-Accountability Meeting *– Thursday, 14 January 2016 from 06:00 – > 09:00 UTC [...]

1 0

Re: [CCWG-ACCT] CCWG ACCT Meeting | 19:00 UTC | Thursday, 7 January
by Dr Eberhard W Lisse Dec. 24, 2015

Dec. 24, 2015

I will be in transit. el On 2015-12-24 18:09 , Brenda Brewer wrote: > *CCWG-Accountability Meeting*– Thursday, 7 January 2016 from 19:00 – > 22:00 UTC [...]

1 0

Re: [CCWG-ACCT] Does the proposed change to the GAC Bylaw create a new "mandatory voting requirement" for the ICANN Board?
by Mark Carvell Dec. 24, 2015

Dec. 24, 2015

Dear Phil and Greg Man of your concerns are familiar of course from last year's consultation on proposed bylaw changes following the joint Board and GAC "BGRI" discussions and agreement on how to implement the ATRT2 recommendations relating to the status of GAC advice and related procedures. Such is the extent now - much more so than in the first 15 years of ICANN - of meaningful interaction between the public policy experts on the GAC and the non-governmental stakeholders directly engaged in developing ICANN policy (witness the GAC-GNSO Consultation Group), as well as between the Board and the GAC thanks largely to implementation of the recommendations of both ATRT reviews, thankfully we can expect substantial rejection of GAC advice by the Board to be an extremely rare occurrence. I would underline in this context that substantial rejection of the advice of such a large number of governments (GAC membership is now 155) acting in concert to safeguard the global public interest and ensure consistency with national and international laws, would be a major, politically highly contentious step for the Board to take. While I can understand stakeholder anxiety about risk of extending the role of governments to the detriment of the successfully embedded multi-stakeholder model that is ICANN, this is why I would argue it is not unreasonable for a decision to reject public policy interest-based advice to be accompanied by a higher threshold than simple majority. The evaluation of that support for rejection needs to be rigorous and a formally instituted and fully accountable voting procedure is the most appropriate means for achieving this. You will recall it was decided in October 2014 to put "on hold" the Board's and the GAC's agreement to institute the two thirds threshold for rejection in the bylaws - partly because the rationale was not well-communicated (and as a consequence an avalanche of objections was received) but also because the timing was wrong as IANA stewardship transition loomed large. I would argue the timing is as right as it will ever be in the context of Stress Test 18 and I welcomed its addition to the proposed text developed by the sub-group. The Board and the GAC have agreed a set procedures consistent with ATRT recommendations for ensuring GAC advice does not fall between any cracks or hang in limbo. See https://www.icann.org/en/system/files/files/atrt-implementation-report-29ja… <https://www.icann.org/en/system/files/files/atrt-implementation-report-29ja…> All elements of formal GAC advice are tracked on an open register that allows the response and follow up to be monitored https://gacweb.icann.org/display/GACADV/GAC+Register+of+Advice This serves to maximise transparency of whether advice is accepted or rejected - and if the latter, of the enactment of the procedure to negotiate and determine if a mutually acceptable solution is possible. Default to acceptance of advice if the Board does not respond to the GAC would not happen. I hope this is helpful in explaining why I believe the procedure in the current formulation of Stress Test 18 should be supported: a) it ensures precision, shared understanding and transparency of fully-informed Board decisions in these rare cases when rejection is a possibility; b) it enables the GAC to fulfil its role and responsibilities in respect of safeguarding the global public interest; and c) it serves the best interests of the ICANN community. Kind regards Mark Mark Carvell United Kingdom Representative on the Governmental Advisory Committee of ICANN Global Internet Governance Policy Department for Culture, Media and Sport mark.carvell(a)culture.gov.uk tel +44 (0) 20 7211 6062 On 18 December 2015 at 15:16, Phil Corwin <psc(a)vlaw-dc.com> wrote: > As the issue of the role of the GAC within post-transition ICANN is the > one most likely to cause Congressional (and perhaps even NTIA) opposition > to the transition proposal -- if there is a perception of an unacceptable > level of governmental influence over ICANN -- it is important to come to a > common and acceptable understanding on this matter. As the ST18 subgroup > came to an agreement only in the last few minutes of its final call it is > perfectly understandable that there may be differing views on the text’s > meaning. > > > > Greg raises an interesting question as to what happens if the GAC provides > some very unpalatable advice and the Board neither advises the GAC that it > intends to take an inconsistent action , or declines to take a formal vote > when the GAC advice is of the consensus variety. Does the advice just wait > in limbo indefinitely, or is there a point in time when it is deemed both > accepted and in effect if the Board has declined to take any action? > > > > *Philip S. Corwin, Founding Principal* > > *Virtualaw LLC* > > *1155 F Street, NW* > > *Suite 1050* > > *Washington, DC 20004* > > *202-559-8597 <202-559-8597>/Direct* > > *202-559-8750 <202-559-8750>/Fax* > > *202-255-6172 <202-255-6172>/cell* > > > > *Twitter: @VlawDC* > > > > *"Luck is the residue of design" -- Branch Rickey* > > > > *From:* accountability-cross-community-bounces(a)icann.org [mailto: > accountability-cross-community-bounces(a)icann.org] *On Behalf Of *Schaefer, > Brett > *Sent:* Friday, December 18, 2015 9:55 AM > *To:* Greg Shatan; Alan Greenberg > *Cc:* accountability-cross-community(a)icann.org > *Subject:* Re: [CCWG-ACCT] Does the proposed change to the GAC Bylaw > create a new "mandatory voting requirement" for the ICANN Board? > > > > Greg, > > > > Agree entirely. This is not what I understood to be the intent of the ST > 18 language. > > > > The more Paul and I have gone over this, the more concerned we have become > over the language. We have expressed similar concerns in our public comment > along with suggestions for alternative text. We need to fix this before > moving forward. > > > > I fully admit to bearing part of the blame in this – we should have > thought this through during the ST 18 discussions. But then we were under > an enormous pressure to meet the deadline and text was being proposed on > the fly during the Adobe chat sessions. The past few weeks have finally > provided some time to reflect and think things through. That reflection > should be taken into account. > > > > Best, > > > > Brett > > > > *From:* accountability-cross-community-bounces(a)icann.org [ > mailto:accountability-cross-community-bounces@icann.org > <accountability-cross-community-bounces(a)icann.org>] *On Behalf Of *Greg > Shatan > *Sent:* Friday, December 18, 2015 12:52 AM > *To:* Alan Greenberg > *Cc:* accountability-cross-community(a)icann.org > *Subject:* Re: [CCWG-ACCT] Does the proposed change to the GAC Bylaw > create a new "mandatory voting requirement" for the ICANN Board? > > > > Alan, > > > > Nowhere does it say that there needs to be a "formal decision." If the > existing Bylaws required a vote, or even a "formal decision," before > entering into the "mutually acceptable solution" process, the Bylaws would > say so. Instead, a more flexible term was chosen -- "determines to take an > action." Assuming competent lawyers, these language choices are meaningful > and deliberate. Elsewhere, the Bylaws clearly state when there are votes > required (some variation of the word "vote" is used ~200 times in the ICANN > Bylaws). "Determines to take an action" is a unique phrase within the > bylaws and virtually unique outside of it -- indeed, all but one Google > result when searching on that term is a reference to this particular > Bylaw. It's fairly clear to me that something less formal than a vote was > intended by choosing this unique phrase. > > > > It's my understanding that this distinction is carried out in the Board's > actual practices, which have utilized the flexibility offered by this > language. As presently drafted, the Board is able to identify a situation > where it appears that they are going to take an action that would be > inconsistent with GAC Advice; at that point, they would approach the GAC, > tell them why and enter into the "mutually acceptable solution" process -- > without requiring a formal vote of the Board. This gives the Board more > flexibility and leeway to work with the GAC, and it's my understanding that > the Board has in fact worked in this manner. The CCWG proposal would take > away that flexibility and mandate a formal vote of the Board, requiring the > Board to take an adversarial stance with the GAC. [Choosng to use the > flatly negative word "reject" instead of the more nuanced phrase "take an > action that is not consistent with" is just the icing on the cake.] > > > > There is another issue raised by this new language. With this revision, > it is far from clear what the status of GAC Advice that not been rejected > by a 2/3 vote? If the Board takes a vote, but the rejection fails to pass, > is the GAC Advice now "accepted" (possibly by a vote of 1/3+1) and binding > on ICANN? What about GAC Advice on which no vote has been taken -- is that > Advice "accepted" and binding on ICANN and, if so, when? [Compare this to > the Community's right to reject a standard bylaws change -- if the > community does not elect to do so, or attempts to do so and fails, that > bylaw clearly become binding upon ICANN.] > > > > The combination of a 2/3 threshold and a mandatory vote to reject GAC > Advice creates a presumption that GAC advice will be accepted. This > presumption is novel and clearly elevates GAC Advice to a new level of > deference within the ICANN process. > > > > Although none of this is explicitly stated in the detailed explanation in > Annex 11, the more I consider this and the more people I talk to, the more > convinced I am that what I've laid out above is exactly what was intended > by some of those involved in the drafting process for the Bylaw revision, > and the rest of us just didn't see it at the time. Since it's not brought > out in the CCWG's explanation, this fundamental change can "fly under the > radar" until the Proposal is approved. > > > > I don't believe that this was the intention of the CCWG. If it's not the > intention of the CCWG, then my alternative wording would remove this > concern. If this is in fact the intention of the CCWG then I think it > needs to be part of the explanation set forth in the proposal, so that the > intent and effect are clear, and any reader can clearly understand what we > have wrought. > > > > Finally, I have to say that this is not an "implementation level" > concern. This is, if you will, a "policy level" concern. If this gets > baked into the accepted proposal, then the implementers will essentially be > bound to carry this out in the implementation (i.e., the drafting of the > "real" Bylaw language). Any later attempt to change a concept stated in > the accepted and transmitted final proposal will face a very high set of > hurdles, at best. Now is the time to deal with this. > > > > Greg > > > > > > > > On Thu, Dec 17, 2015 at 3:22 PM, Alan Greenberg <alan.greenberg(a)mcgill.ca> > wrote: > > Greg, you say that the current Bylaws do not reference voting. The current > wording ( > https://www.icann.org/resources/pages/governance/bylaws-en/#XI-2.1j) is > "In the event that the ICANN Board determines to take an action that is not > consistent with the Governmental Advisory Committee advice..." > > How else is the Board able to formally decide on anything other than by > voting? > > Alan > > At 16/12/2015 03:09 AM, Greg Shatan wrote: > > All, > > In reviewing the Third Draft Proposal, concerns have been raised within my > constituency that the proposed Bylaw does more than replace an existing > "majority" threshold with a new "2/3" threshold. The concern is that the > proposed Bylaw introduces a "mandatory vote" by the Board in order to > reject GAC Advice where the Bylaws do not currently require a Board vote. > Further, there appears to be a concern that, if the Board does not take a > vote and affirmatively reject a piece of GAC advice, then that GAC advice > becomes binding on ICANN. > > These concerns stem from a reading of the draft Bylaw (new language in > red): > > The advice of the Governmental Advisory Committee on public policy matters > shall be duly taken into account, both in the formulation and adoption of > policies. In the event that the ICANN Board determines to take an action > that is not consistent with the Governmental Advisory Committee advice, it > shall so inform the Committee and state the reasons why it decided not to > follow that advice. Any Governmental Advisory Committee advice approved by > a full Governmental Advisory Committee consensus, understood to mean the > practice of adopting decisions by general agreement in the absence of any > formal objection, may only be rejected by a vote of two-thirds of the > Board, and tThe Governmental Advisory Committee and the ICANN Board will > then try, in good faith and in a timely and efficient manner, to find a > mutually acceptable solution. > > â€‹The current language of the Bylaw makes no reference to voting, only to > the far more ambiguous "determines to take an action." As such, adding a > reference to a vote can be seen to add a new element (aside from the > introduction of a 2/3 threshold): the element of a bylaws-mandated vote. > Similarly, the statement that GAC Advice can only be rejected by a vote of > the Board can be read to state that if no such vote is taken (or if such > vote is taken and fails) that the GAC Advice is then something ICANN is > bound to follow. > > I don't think either of these things were intended by the CCWG. Whether > they are misreadings of our draft language or unintended consequences of > the drafting, this concern is troubling. If it is the intent of some of > those drafting this language to force a vote where none is currently > required, then that is even more troubling. > > I would appreciate some clarification on these matters that I can bring > back to my group. > > I would also appreciate the CCWG considering a change in language to > remove this ambiguity which is currently causing great consternation in my > group. > > I suggest the language below. This m > ore closely track > â€‹sâ€‹ > the language of the existing bylaw and avoid the use of the term "vote," > with its potential unintended consequences: > > The advice of the Governmental Advisory Committee on public policy matters > shall be duly taken into account, both in the formulation and adoption of > policies. In the event that the ICANN Board determines to take an action > that is not consistent with the Governmental Advisory Committee advice, it > shall so inform the Committee and state the reasons why it decided not to > follow that advice. > > â€‹ > > If the Board > > â€‹ > > determines to take an action that is not consistent with > > Governmental Advisory Committee advice approved by a full Governmental > Advisory Committee consensus, understood to mean the practice of adopting > decisions by general agreement in the absence of any formal objection, > > â€‹ > > â€‹such determination must be supported by > > two-thirds of the Board, > > and the Governmental Advisory Committee and the ICANN Board will then try, > in good faith and in a timely and efficient manner, to find a mutually > acceptable solution. > > â€‹ > > > > I would appreciate your thoughts on this point and the revised language. > Thank you. > > Greg > ------------------------------ > > *Brett* *Schaefer* > > * Jay Kingham Senior Research Fellow in International Regulatory Affairs > Margaret Thatcher Center for Freedom Davis Institute for National Security > and Foreign Policy* > The Heritage Foundation > 214 Massachusetts Avenue, NE > Washington, DC 20002 > 202-608-6097 > heritage.org > > _______________________________________________ > Accountability-Cross-Community mailing list > Accountability-Cross-Community(a)icann.org > https://mm.icann.org/mailman/listinfo/accountability-cross-community > > > ------------------------------ > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2016.0.7227 / Virus Database: 4477/11098 - Release Date: 12/01/15 > Internal Virus Database is out of date. > > _______________________________________________ > Accountability-Cross-Community mailing list > Accountability-Cross-Community(a)icann.org > https://mm.icann.org/mailman/listinfo/accountability-cross-community > >

3 3

Work plan in January
by Mathieu Weill Dec. 24, 2015

Dec. 24, 2015

Dear Colleagues, In line with the work plan discussion held on call #72, we wish to inform you that we have decided to increase the number of calls per week to two to allow for an in-depth analysis of the input received on our Draft Proposal, and discuss any complex requests for change there may be. It is currently foreseen that this frequency of calls will only apply to the month of January. As discussed on 22 December, these calls will be plenary and topic-based. You will receive a list of topics in advance of the meetings so that you may plan your participation accordingly. Duration of the calls will also be extended to 3 hours to allow for ample time to complete our tasks. Calls will be cancelled (and/or duration will be reduced) if deemed unnecessary. Please note that staff will send invites as well as overview of the conference call calendar shortly. We look forward to reconvening in January and wish you a happy holiday season for those of you who celebrate. Best regards Mathieu Thomas - León

1 0

[blog] IANA Stewardship Transition Implementation Planning
by Grace Abuhamad Dec. 23, 2015

Dec. 23, 2015

Original link: https://www.icann.org/news/blog/iana-stewardship-transition-implementation-… IANA Stewardship Transition Implementation Planning: Taking Stock of the Last Two Months and Looking Forward to 2016 <https://www.icann.org/news/blog/iana-stewardship-transition-implementation-…><https://www.icann.org/news/blog/iana-stewardship-transition-implementation-…><https://www.icann.org/news/blog/iana-stewardship-transition-implementation-…><https://www.icann.org/news/blog/iana-stewardship-transition-implementation-…><https://www.icann.org/news/blog/iana-stewardship-transition-implementation-…><https://www.icann.org/news/blog/iana-stewardship-transition-implementation-…> The last update<https://www.icann.org/news/blog/iana-stewardship-transition-implementation> I provided was just over two months ago as we were heading into ICANN54 in Dublin. Our goal at that time was to receive feedback and better understand the community's need for reporting and oversight of implementation planning for the IANA Stewardship Transition. In looking back at our progress since October, we achieved this and much more. We are now providing monthly status updates on implementation planning efforts to the leadership teams of the CCWG-Accountability, CWG-Stewardship, CRISP Team, IANAPLAN WG, GNSO, ccNSO,IETF, IAB, and RIRs on the Transition Program Facilitation Management calls<https://www.icann.org/resources/pages/transition-facilitation-2015-09-23-en>. Additionally, we have established a reporting cadence with the CWG-Stewardship by providing more detailed implementation planning status updates on the group's bi-weekly calls. We are also working with all of the operational communities on defining service levels and documenting our relationships with them, as well as on theIANA Intellectual Property Rights. On the CCWG-Accountability side, we look forward to engaging with the group once its Work Stream 1 Recommendations are finalized. Shortly after ICANN54, we launched a dedicated web page<https://www.icann.org/stewardship-implementation> to provide the community with updates on implementation planning activities. We have been building out this web page to provide a more seamless browsing experience, including sort and filter capabilities. Be on the look out for more on this in the coming weeks. On the U.S. Government side, we have been engaging with NTIA on our planning efforts. The feedback from NTIA has been very helpful in developing our plans and overall timelines to allow ICANN to plan for implementing as early as possible while respecting the current IANA Functions Contract. In my pre-ICANN54 blog, I wrote that our assessment showed that we would need four months to complete the IANA Stewardship Transition implementation, assuming the proposals are approved. This timetable has not changed. However, we hope that our continued collaboration with the community, engagement with NTIA, and careful project planning will enable us to complete the necessary implementation as efficiently as possible to meet a conclusion in time for a transition in 2016. We will continue to monitor progress, and regularly report back to the community. As we head into 2016, our team looks forward to further collaboration with the community toward a successful and on-time transition. Happy holidays to those celebrating this season and best wishes into the New Year!

1 0