[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