[CWG-Stewardship] Notes, Recordings, Transcript DT-F Meeting #1 - 13 April

Brenda Brewer brenda.brewer at icann.org
Mon Apr 13 15:59:18 UTC 2015



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.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150413/76d96e00/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 92 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150413/76d96e00/image001-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5035 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150413/76d96e00/smime-0001.p7s>


More information about the CWG-Stewardship mailing list