Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Blogs 

 

Most Recent Blog Update 

Author:  Jordan Carter

Date:  12 October 2015 10 May 2016
Original LinkPost:  https://internetnz.nzwww.icann.org/news/blog/hopes-dublin

As the 54th ICANN Meeting in Dublin approaches, CCWG-Accountability member and InternetNZ Chief Executive Jordan Carter sets out his hopes for the meeting, and his firm conviction that a path to consensus and speedy resolution of the accountability debate is open – and should be grabbed. 

It’s crunch time.

In Dublin starting this Friday, a significant test faces the Internet community and ICANN. A real opportunity is there for consensus to emerge around a solid plan for improvements to ICANN’s accountability. These are improvements that would see the completion of the accountability framework for ICANN's stewardship of the IANA functions (alongside what is in place for the other communities (numbers and protocols)).

Making that happen is going to require everyone to be flexible. That's a challenge, but an achievable one.

By way of context, the CCWG is one of the two tracks of the IANA Stewardship transition, together with the ICG. Both are working to make ICANN an effective steward of the Internet's domain name system and a responsible, secure & reliable operator of the IANA Functions for the three operational communities (names, numbers and protocols). The CCWG's working method has been a multistakeholder one, in keeping with how the Internet community makes policy best.

After starting work at the end of 2014, the CCWG released a first draft proposal for how to improve ICANN's accountability in May, and a second in August. Since public comments on the second draft proposal closed a month ago, the CCWG has been analysing the feedback offered by the community, and has also spent time in a side effort to understand the logic behind the Board’s counter-proposal.

In parallel, as has been the case after each moment of public feedback, CCWG participants have been thinking through how to take the proposal to the next level – taking the feedback into account, clarifying the proposal, thinking about how to change and improve things for a final effort at a proposal that can be tested for consensus.

Compared with the most recent draft, here are some key changes that are part of the discussion that could lead to a new synthesis:

  • A consensus approach for decisions about using the new community powers proposed by the CCWG (replacing the voting-based system)
  • Much clearer explanation of how the reserve powers the CCWG has been dealing with fit into and build on existing ICANN processes (particularly the importance of consultation and collaboration before community powers come into play)
  • The replacement of a membership model with a designator model (which would reduce the direct enforceability of some of the community powers, but would guarantee that board/director removals and bylaws change approvals were beyond question – and which arguably is consistent with how ICANN operates today)
  • A commitment to continuous improvement of ICANN’s accountability (including perhaps through a longer-term governance review)
  • Retention of the basic framework of improved review and redress through a stronger IRP, fundamental bylaws and so on 

The above synthesis gives all key parties some wins: the basic framework of the CCWG’s work would be intact, the model of multistakeholder policy development upheld, many of the Board’s concerns taken into account, and no significant delays added to slow the transition down. Legal advisors and CCWG members have been fleshing out this approach, ready for discussion on Friday.

It seems to me that it would be viable to complete a proposal along these lines and have it out for public comment before the end of the year, and SO/AC approval early in 2016. That’s probably the fastest possible, without putting at risk the quality of the proposal. And since we’ve done that twice, and caused confusion and concern by skimping time to get the proposal clear and readable, it isn’t sensible to make the same mistake a third time.

To me that looks like an outcome worth trying very hard for – and if we can manage it, an outcome to be very happy with.

As ever, there are some risks.

Some participants have started throwing bottom lines around. Those participants need to back off that, otherwise the chances of a consensus being achievable become very small.
There may be a temptation for the ICANN Board to “box the CCWG in”, trying to monster it or the community into adopting a proposal that doesn’t meet the community’s accountability requirements in the name of timeliness. (In a separate post I have already pointed out that it is ICANN that is responsible for the time pressure, so the irony of an approach like this would be rich.)
The technical communities – numbers and protocols – could lose confidence that this accountability process, which is best seen as a "catch up" for names to attain accountability as good as protocols and numbers already have - will ever conclude. Yet if it doesn't, the accountability framework for the IANA functions would be incomplete. This in turn could risk the integrity of ICANN and its role as the IANA Functions Operator for the three communities.

iana-stewardship-transition-planning-update-volume-2

 

IANA Stewardship Transition Planning Update (Volume 2)
 

Root Zone Management

The Root Zone Management implementation planning track contains projects relating to changes to the Root Zone Management System (RZMS) to remove NTIA's authorization role, parallel testing of the production and parallel test RZMS systems; and the development, and execution of an agreement with Verisign as the root zone maintainer.

Root Zone Management System (RZMS) Parallel Testing

Status update:

It has been one month since the start of the parallel testing period and everything continues to go smoothly. Click here to view Verisign’s daily Parallel Operations Root Zone Management System Comparison Reports of all the root zone files generated.

In addition to Verisign’s daily reports, ICANN has posted the first of three Monthly Reports on RZMS Parallel Testing Progress during the testing period. The report is available on ICANN’s dedicated Parallel Testing landing page.

In the event that no unexplained differences in root zone files are identified between the production RZMS and the parallel test RZMS, the testing period will end successfully on 5 July 2016.

Documents/announcements posted:

Mailing list:

  • None.

Root Zone Maintainer Agreement (RZMA)

Status update:

Discussions between ICANN and Verisign to finalize details of the RZMA are continuing. The two parties have coalesced around many key elements of the agreement and hope to have a final draft by the end of the month.

Once the draft RZMA is finalized it will be made publicly available on icann.org.

Documents/announcements posted:

  • None.

Mailing list(s):

  • None.

 

Stewardship Transition

The Stewardship Transition planning track contains projects to prepare relationship documentation with the operational communities, creation of a Post-Transition IANA (PTI) entity, establishment of a Customer Standing Committee (CSC) and a Root Zone Evolution Review Committee (RZERC), operationalizing the IANA customer service escalation mechanisms and Service Level Agreements (SLAs).

Post-Transition IANA (PTI)

Status update:

ICANN has been working with the Implementation Oversight Task Force (IOTF) on various activities relating to the PTI. Summaries of PTI formation documents (Bylaws, articles of incorporation) as well as the conflict of interest policy have been shared with the IOTF.  ICANN continues to work with the IOTF to finalize the process and timing of review for these documents as well as for the ICANN-PTI contracts.

Documents/announcements posted this week:

  • None.

Mailing list(s):

Customer Standing Committee (CSC)

Status update:

In the CWG-Stewardship proposal, the Domain Names community recommended that a CSC be formed to replace NTIA’s role as it relates to monitoring performance of the IANA naming function. The composition of the CSC will include members and liaisons from all ICANN Supporting Organizations(SOs) and Advisory Committees (ACs).

A Request for Appointment is expected to be sent to SOs and ACs this month to appoint members and liaisons to the CSC using their internal processes.

Documents/announcements posted this week:

  • None.

Mailing list(s):

Root Zone Evolution Review Committee (RZERC)

Status update:

The RZERC Charter (v4) was circulated to the CWG-Stewardship on 4 May 2016. The CWG-Stewardship will discuss the Charter on their 12 May 2016 call, and members and participants of the group are encouraged to provide any comment by 23:59 UTC on 17 May 2016.

Following analysis and incorporation of any input received from the CWG-Stewardship, ICANN will post the Charter for a 30-day public comment period.

Documents/announcements:

Mailing list(s):


 

Accountability Enhancements

The Accountability Enhancements track contains plans to implement enhancements to ICANN’s Independent Review and Reconsideration Request processes, to update ICANN’s governance documents, and to operationalize new community powers defined by the Cross Community Working Group on Enhancing ICANN Accountability (CCWG-Accountability).

ICANN's Bylaws

Status update:

ICANN and the community are in the middle of a 30-day public comment period on the new draft ICANNBylaws. Any interested party can submit comments to the public comment forum until 23:59 UTC on 21 May 2016

Adoption of the new Bylaws by the ICANN Board is anticipated for on or around 27 May 2016. Once new ICANN Bylaws have been adopted, ICANN will notify NTIA so they can complete their anticipated 90-day review of the IANA Stewardship Transition Proposal.

Documents/announcements:

Mailing list(s):

  • The ICANN leadership could make a mistake with the Dublin meeting, and try to repeat the failed pressure tactics it tried with the CCWG in September (on calls and in Los Angeles) – to put it politely, such an approach would be sure to backfire and reduce the chance of consensus being reached.
  • The bigger picture regarding risk here, which plays on my mind a lot, has to do with the fact that the world’s eyes are on us.

    If the ICANN community cannot arrive at a consensus for accountability improvements, the chances are that the IANA Stewardship transition will be unnecessarily delayed – possibly not even being complete by 30 September 2016. 

    A further delay (and it would only be a delay – the cat is out of the bag, and the transition is inevitable – it’s only a question of when) would have a stack of downsides.

    It would embolden critics of the multistakeholder model.

    It would annoy and exasperate the technical communities, risking the effort to have a single IANA Functions Operator serving all three communities. 

    It would be a red light for Congress in paying very close attention to what is going on.

    It would be an admission that the players in the ICANN environment can’t reach consensus on an important issue – not a great advertisement for a model that is premised on achieving consensus as its main strength in legitimately coordinating the Internet’s system of unique identifiers.

    High stakes for all of us. 

    It’s reasonable to have some optimism about the chances of a consensus emerging. Nobody’s interests are compromised by the sort of synthesis the CCWG is working on.

    As we count down the days to Dublin, let’s recommit ourselves to building an accountability settlement that works. Let’s remind ourselves that consensus and being flexible isn’t about “losing” anything and doesn’t have to be about second-bests.

    It really can be a collaborative, open process that brings all of us to a better place. Idealistic? I don’t think so: it’s why I support ICANN, it’s why I support the transition, and it’s why I want us to succeed this week and next. It’s a model that works. Let’s use it. 

    That’s my hope for Dublin – a hope I welcome you to share and to turn into reality.

  • JordanC's blog 
  • Log in or register to post comments