Dear all, The notes, recordings and transcripts for the CWG IANA DT-F Meeting #1 on 13 April are available here: https://community.icann.org/pages/viewpage.action?pageId=52896691 Action Items Action Alan: will suggest language on the list re need to have clarity around change of cooperative agreement Action Alan: Check with IANA what is made public and what wil be made public. Action: Alan, and staff (B&B) to initiate drafting. Notes Task for DT F Recorded in template Suggestion to distinguish that need to be addressed before transition and could be done afterwards (see Alan's summary email) DNSSEC key management. NTIA operational involvement limited to changes going into root-zone David: No particular role in day-to-basis. NTIA oversees/approves (right word not clear) plan to change plans for DNSSEC key management Basic Recommendation DT F DT D recommendation, no Authorization needed. David C: No contractual relation between IFO and RZM What should be core recommendation: RZM should accept changes from IFO David C: No contractual relation between IFO and RZM. Suggest to enter into contract Milton: 2 suggestions: - formal relationship between IFO and RZM - NTIA needs to act Alan Question: should NTIA step out of or change cooperative agreement as part of the Transition? Milton: changes are needed, given language in cooperative agreement re Authorization by NTIA for changes David C: NTIA needs to approve changes explicitly to make changes. Action Alan: will suggest language on the list Questions Alan as listed in email Is there an opportunitry for accidental change, once change is submitted? Accidental changes not likely (software bugs aside) Potential for out-of policy changes? Is there a need to look at it in more detail. Need to understand what is in policy and what is not Milton: supports need to check, put checks and balances in policy/procedures and flag Chuck: Two kinds of policy. Standards and policy developed by ccNSO and GNSO. IANA operator or RZM do any interpretation by policy developed by ccNSO and GNSO. They do interpret technical side of policy (standard). The flow for ccTLD and gTLD is different. Alan: No need to flesh out in recommendation, but may need to delve into later. Chuck: Be specific about the type of policy. David C: under latest version IANA Function contract, no longer role of ICANN Board. IANA staff needs to do interpretation Alan: Check if there is need to change current process around Board . What does it mean if NTIA goes away. Limit this group to absence of NTIA Potential for accidental or malicious or omissions Alan: potential solution (comparing changes) David: if change request is made public, then comparison is possible, for example by TLD operator. David: presumption of confidentiality. Alan: Go to community to check if changes should remain confidential. Chuck : note the Alan: Recommend that IANA makes a change request public ACTION Alan: Check with IANA what is made public and what will be made public. Need to replace NTIA in discussion regarding substantive Root Zone changes. David C: possibly introduce trust but verify mechanism, Suzanne: Need to make a contract change necessary, Also needed, mechanism to be able to spend considerable amounts of money to prepare for potential changes ( for example, introduction of DNSSEC). Suggestion to formulate requirement. Alan: at times involvement of NTIA may have led to delays. Another way around, did NTIA involvement add value? Form direct experience, care and consideration have been put into process of changes. Milton: NTIA had to agree, and then change the contract. Somebody needsd to be in position to be convinced. These questions should not be resolved by DT F, are part of broader discussion of authority to write the contract ( governance issue) Alan: Someone needs to ask the right questions. David: NTIA does have access to vast array area of resources and Expertise (example around DNSSEC deployment) Alan: There are advantages of NTIA's involvement and these need to be replaced. Concentration of power to change in one single entity is issue. Chuck: current system of two entities, preforming the IFO and RZM role good practice, and should be maintained. Alan: what should be recommendation on this point moving forward? Accession as currently stands: NOT integrate the roles in to one single entity is accepted. The two-man rule is preferred. Milton: Support separation of roles Need to address of Security? Milton: separation of structure might be good idea. David C: Does this need to be part of robustness? Alan: could be David C: Budget Numbers need to be upgraded if infrastructure would be separated. revisit recommendation DTO Chuck: In discussion with Xavier, cost of separation were clarified. Cost shoul dno tbe primary factor, but ther cost factors come into play Alan: Need to mentioned, but not part of architecture recomemndation Potential change process slowing down the speed of RZ change implementation. Chuck: need to express best efforts should be made not to slow down. How to go forward? Alan, and staff to initiate drafting AOB Chuck: need for change of automation change when NTIA is removed. Identify changes needed? David C: Currently change in process may be needed, In short time as long as Verisign maintains role as RZM, no major changes needed.
