At-Large 2nd Draft Proposal of the Cross Community Working Group to Develop an IANA Stewardship Transition Proposal on Naming Related Functions Workspace

There may be need to further clarify the following:

- Who appoints and fires PTI staffs (is it ICANN board or PTI board?)

- Is there an IANA "naming" function department and specific staff/resources already existing that would make movement easier (as i presume IANA staff does multiple roles across the 3 operational communities). My understanding is that there is currently IANA department and not "IANA naming department"

- As it concerns data, does it mean PTI would assume ownership of the data?

All good questions that should be explicitly addressed. What we are putting into IANA is the entire IANA, not just the naming functions. The relations with the other communities is covered by footnote.5 on page 21. Regarding data ownership, my understanding is that IANA, ICANN and NTIA have always maintained that all data that compises the root zone is in the public domain. However, there should be expicit mention of the internal files of IANA all being transferred.

- Does Any of the transfer includes IANA trademarks?

Given the amount of time the other groups spent on this, I think that we wisely ignored it (it was a DT that we deferred, but will have to revisit). It is less of a problem for us than the other groups, because ICANN will stay the Steward of the names function regardless of what the other groups do.

- The CWG may need to consider extra cost that would emerge on recruiting more staff (since there may be less multi-tasking of staff going forward)

 Yes, that is part of the budgeting process.

It may be good to determine what will happen should incase ICANN refuses to provide adequate budget to PTI, also it needs to be clear who approved PTI's budget i.e is it the PTI board, ICANN board or ICANN community (as represented by SO/AC leaders)

 That is handled by the ICANN Accountability processes.

"The contract would provide for automatic renewal, but subject to potential non-renewal by ICANN if recommended by the IANA Function Review "

I think it needs to be clear that automatic renewal is subject to the outcome of the IFR, so i would really suggest removing "automatic" from the statement since there will be an action that will occur before any contract renewal happen.

 "but subject" covers part of that, and an IFR recommendation to terminate covers the rest I would think.

 "The outcomes of reports submitted to the CSC, reviews and comments received on these reports during the relevant time period will be included as input to the IFR"

It is my hope that the reports referred to is those from IANA (which will be available to the public including CSC). That said, its not clear who initiates this process, is it the IFR or PTI?

 The IFR is the process. It is initiated with automatically on a periodic basis, or based on a problem.

- Is PTI going to be managing all IANA operations (including those of the other 2 operational communities?)

The answer is that this is the Post-transition IANA and it does whatever IANA  does. But you are correct that this should be made clear at the start.

 "In the event of a Special Review being proposed,the ccNSO and GNSO should consult with both members and non-member TLDs, in the light of the consultations, the Councils can decide by a supermajority to call for a special review"

Isn't there supposed to be an MS input beyond (GNSO/ccNSO) before such special review can be called. I mean where does ALAC view gets represented as part of the call process. Does ALAC really need to wait until IFR before they can make their views known?

I am not sure we need that, but perhaps that falls under the re-instated MRT as I mentioned.