Notes-Recordings-Transcript links for CWG IANA DT-F Meeting #2 on 15 April
Dear all, The notes, recordings and transcripts for the CWG IANA DT-F Meeting #2 on 15 April will be available here: https://community.icann.org/pages/viewpage.action?pageId=52896693 Notes DT F call 15 April 2015 Comments received from Milton Timing CWG: Recommendations DT F need to be read by tomorrow Structure: Recommendations that MUST be included Identify topics to be addressed later. Two versions: short form of recomemndation and whatever size is necessary Suggestion use Milton's suggestions for short document Identifying NTIA "routine " Authorization goes away 1 a. Section Why say in short term? Currently prohibited to make changes. Alternative: eiither change before software, or handled on interim basis, without any need to make change Chuck suggestion, make explicit. what is meant Changes to be made 1 b. .Chuck suggestion, third sentences. Add, nor whether what will be in place, Suggested change: The exact form of the latter transition is not currently known, nor what whether anything will replace the current Cooperative Agreement. However, there will likelymay be a requirement to have a formal agreement between the IANA Function Operator and The Root Zone Maintainer. Does the group want to specify additional checks and balances or leave it for later stage? David: include as a recommendation caution not to go one entity Chuck: suggest # 6 as suggestion Recommendation is: additional analysis is needed Recommendation 2 NTIA more extensive than anticipated first NTIA is getting into fair amount Question: Is DT F going to make a recommendation or someone else David: Sensitivities invovled, appropriate to make recoeedation that CWG identify a party that explores issues. NTIA approval needed for different categories Authorization of changes On day-to day basis Publish reporting Approval monthly reports Document approval Question Alan: how often approval and is it real function? Question: what needs prior community approval, what can be done by IFO, with out prior approval by community Topic needs to be considered, what needs to be reviewed/ approved Unclear what rationale was for NTIA. Question What is current rationale, to provide guidance.? Are there real issues or just concerns of USG.? Focus on structural aspects and not on presentation aspects. Question Alan: Are ther topics that need to be discussed outside IAAN, but not fit for public comment? Issues specific to specific situation or cases could be anissue, but not in general items Capture notion that check for everything creates issues by itself, at the same some items may need to be Default should be on openness and tranparancy as main principle, in some operational circumstances,confidentiality may be required -> need to be documented Interaction is vast majority of cases be open and transparent. Note that ATRT 1 and ATRT 2, transparnacy is needed and need to be in DNA Chuck: timing could make it an issue. >making it public when changes already made, non-issue Section 3. Question: is this in DT O? DT O recommended that as the solution get more well-defined to check whether budget has covered them DT O has included general recommendation . However suggestion to re-amphasize point. Cheryl: In addition to DTO recommendation DT F specially notes inclusion of Issues Warranting further discussion Simply listing allows others to pursue these items ( CSC or part of Periodic review If considered critical infrastructure then items should be looked at in a consistent manner. Stornger suggestion that study must be done to be considered by chair Section 5. What should be public and not be public Recommendation needs to be added on in line with discussion David: Suggest to take into account phasing of change request process. Point for publication is when validation has been completed. What really matters is that changes has been accepted for processing Agree it should be studied. In specific cases of delegation and redelgation of ccTLD that third parties. Introduce new section Principles that should be adhered to Include transparence as well ( Section 5) Section 6 Making a statement of concentration of power is appropriate suggestion Chuck Currently updating the Root Zone requires the active participation of three parties, the IANA Function Operator, the Root Zone Maintainer and the NTIA. Post transition there will only be the first two. DT-F recommends that the remaining two functions should never be awarded to a single entity. Note that the implications of this might vary depending on whether any or all of the robustness issues identified in Issue 1 have been addressed." What i spurpose of separation of IF and RZM, is to esnure two person control. Reduce risk of failures. malicious behaviour etc. Risk mitigation tool This looks at changes proposed to change implemented. Two parties control does not fix all problems, but catches some Sugestion: there should be no concentration of power but we need to explore how best to implement it Section 7 Concern: if community wants to make slower What i spurpose of separation of IF and RZM, is to esnure two person control. Reduce risk of failures. malicious behaviour etc. Risk mitigation tool This looks at changes proposed to change implemented. Two parties control does not fix all problems, but catches some
For my suggested edits please see the attached redline, in particular recommendations 1.b and 6. What I put in the chat didn't show the deleted text as deleted so what is in the notes doesn't make sense. Chuck From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Brenda Brewer Sent: Wednesday, April 15, 2015 6:04 PM To: cwg-stewardship@icann.org Subject: [CWG-Stewardship] Notes-Recordings-Transcript links for CWG IANA DT-F Meeting #2 on 15 April Dear all, The notes, recordings and transcripts for the CWG IANA DT-F Meeting #2 on 15 April will be available here: https://community.icann.org/pages/viewpage.action?pageId=52896693 Notes DT F call 15 April 2015 Comments received from Milton Timing CWG: Recommendations DT F need to be read by tomorrow Structure: Recommendations that MUST be included Identify topics to be addressed later. Two versions: short form of recomemndation and whatever size is necessary Suggestion use Milton's suggestions for short document Identifying NTIA "routine " Authorization goes away 1 a. Section Why say in short term? Currently prohibited to make changes. Alternative: eiither change before software, or handled on interim basis, without any need to make change Chuck suggestion, make explicit. what is meant Changes to be made 1 b. .Chuck suggestion, third sentences. Add, nor whether what will be in place, Suggested change: The exact form of the latter transition is not currently known, nor what whether anything will replace the current Cooperative Agreement. However, there will likelymay be a requirement to have a formal agreement between the IANA Function Operator and The Root Zone Maintainer. Does the group want to specify additional checks and balances or leave it for later stage? David: include as a recommendation caution not to go one entity Chuck: suggest # 6 as suggestion Recommendation is: additional analysis is needed Recommendation 2 NTIA more extensive than anticipated first NTIA is getting into fair amount Question: Is DT F going to make a recommendation or someone else David: Sensitivities invovled, appropriate to make recoeedation that CWG identify a party that explores issues. NTIA approval needed for different categories Authorization of changes On day-to day basis Publish reporting Approval monthly reports Document approval Question Alan: how often approval and is it real function? Question: what needs prior community approval, what can be done by IFO, with out prior approval by community Topic needs to be considered, what needs to be reviewed/ approved Unclear what rationale was for NTIA. Question What is current rationale, to provide guidance.? Are there real issues or just concerns of USG.? Focus on structural aspects and not on presentation aspects. Question Alan: Are ther topics that need to be discussed outside IAAN, but not fit for public comment? Issues specific to specific situation or cases could be anissue, but not in general items Capture notion that check for everything creates issues by itself, at the same some items may need to be Default should be on openness and tranparancy as main principle, in some operational circumstances,confidentiality may be required -> need to be documented Interaction is vast majority of cases be open and transparent. Note that ATRT 1 and ATRT 2, transparnacy is needed and need to be in DNA Chuck: timing could make it an issue. >making it public when changes already made, non-issue Section 3. Question: is this in DT O? DT O recommended that as the solution get more well-defined to check whether budget has covered them DT O has included general recommendation . However suggestion to re-amphasize point. Cheryl: In addition to DTO recommendation DT F specially notes inclusion of Issues Warranting further discussion Simply listing allows others to pursue these items ( CSC or part of Periodic review If considered critical infrastructure then items should be looked at in a consistent manner. Stornger suggestion that study must be done to be considered by chair Section 5. What should be public and not be public Recommendation needs to be added on in line with discussion David: Suggest to take into account phasing of change request process. Point for publication is when validation has been completed. What really matters is that changes has been accepted for processing Agree it should be studied. In specific cases of delegation and redelgation of ccTLD that third parties. Introduce new section Principles that should be adhered to Include transparence as well ( Section 5) Section 6 Making a statement of concentration of power is appropriate suggestion Chuck Currently updating the Root Zone requires the active participation of three parties, the IANA Function Operator, the Root Zone Maintainer and the NTIA. Post transition there will only be the first two. DT-F recommends that the remaining two functions should never be awarded to a single entity. Note that the implications of this might vary depending on whether any or all of the robustness issues identified in Issue 1 have been addressed." What i spurpose of separation of IF and RZM, is to esnure two person control. Reduce risk of failures. malicious behaviour etc. Risk mitigation tool This looks at changes proposed to change implemented. Two parties control does not fix all problems, but catches some Sugestion: there should be no concentration of power but we need to explore how best to implement it Section 7 Concern: if community wants to make slower What i spurpose of separation of IF and RZM, is to esnure two person control. Reduce risk of failures. malicious behaviour etc. Risk mitigation tool This looks at changes proposed to change implemented. Two parties control does not fix all problems, but catches some
participants (2)
-
Brenda Brewer -
Gomes, Chuck