Implementation Oversight Task Force (IOTF) Meeting Call #7 - 27 April 2016

Slide Note
Embed
Share

The Implementation Oversight Task Force (IOTF) conducted its 7th meeting on 27 April 2016, addressing key agenda items including the RZERC Charter, IANA Escalation Mechanism, and Document Review Process & Timeline. The RZERC Charter's purpose focuses on reviewing and suggesting architectural and operational changes to the root zone, among other responsibilities. The committee operates transparently, with meetings held as necessary and decisions based on consensus.


Uploaded on Oct 05, 2024 | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. Implementation Oversight Task Force (IOTF) Meeting Call #7 | 27 April 2016

  2. Agenda 1. Opening Remarks 2. Implementation Items - RZERC Charter: Obtain final agreement from IOTF on the draft circulated - IANA Escalation Mechanism: Is there any other comments and feedback from the IOTF on Chuck s clarification? - Document Review Process & Timeline: 1) Continue discussion regarding document review process, and 2) review timeline 3. AOB 4. Closing Remarks | 2

  3. RZERC Charter

  4. RZERC Charter Purpose Review and provide input regarding proposed architectural and operational changes to the root zone. As determined necessary by the committee, propose architectural and operational changes to the Root Zone for consideration by the ICANN Board. Act as a consultation body for ICANN during the RFP process for the Root Zone Maintainer, if needed Consider issues raised to the committee to identify any potential security, stability or resiliency risks to the architecture and operation of the root zone. Scope of Responsibilities Coordination with the committee s respective organizations and communities, and if appropriate, external experts, to ensure that relevant bodies were involved in decision and relevant expertise was available. For operational and architectural changes that impose potential risk to the security, stability, or resiliency of the root system (as identified by one or more committee members and agreed by a simple majority of members), coordinate a public consultation process via the ICANN public comment forum regarding the proposed changes, including the identified risks. Act as a consultation body for ICANN during the issuance and consideration of an RFP for the Root Zone Maintainer, if needed. Coordinate with the Customer Standing Committee (CSC) as needed; Composition One ICANN Board member (possibly as Chair), senior IANA Function Operator administrator or delegate, Chairs or delegates of the SSAC, RSSAC, ASO, IETF, a representative of the GNSO RySG, a representative of the ccNSO and a representative of the Root Zone Maintainer. The committee will select its chair. | 4

  5. RZERC Charter - Continued Meetings Will meet as frequently as necessary, with at least one meeting per calendar year. Regular meetings may be called upon with a fourteen-days notice by either the Chair or two members of the Committee acting together. Meetings to address urgent issues may be called in a manner calculated to provide as much notice as possible to the members of the Committee. Meetings may take place telephonically or, as prudent, face-to-face. E-mail and other Internet-based discussions are not deemed to be meetings. Voting and Quorum Decisions and actions of the Committee shall be taken by consensus. Such consensus may be determined via Internet-based discussions without the need for a meeting. Records of Proceedings Minutes or other records of Committee sessions shall be posted following approval by the Committee. The Committee shall operate as openly and transparently. In the event that making certain deliberations public would create a risk to the security or stability of the Internet DNS, the Committee shall specifically identify that as a reason for withholding parts of their meeting records. Conflicts of Interest Committee members must provide statements of interest and confirm adherence to a Conflicts of Interest policy in their Committee service. Review The Charter of the Committee shall be reviewed at least every 5 years, and a review may be initiated more frequently if determined necessary. | 5

  6. IANA Escalation Mechanism

  7. IANA Escalation Mechanism Question: Is the omission of the ICANN President and CEO from the escalation step within the paragraph 1367 of Annex I intentional? Chuck Gomes clarification (21 April 2016 via IOTF mailing list): As I suspected on the call this week, it was intentional. Thanks to Marika for digging into meeting notes to confirm this. From my own personal point of view, considering that anyone can file a complaint in Phase 1, it seems like overkill to escalate a complaint in Phase 1 to the President and CEO, and if it is a recurring problem or of a more significant nature, registry operations or the ccNSO or GNSO may escalate it further via Phase 2. Question: Flowchart #1 and #3 of the Annex J are titled the same ( IANA Problem Resolution Process ), but the contents of the flowcharts differ. Is the difference intentional? Chuck Gomes clarification (21 April 2016 via IOTF mailing list): As you can see, the one on page 115 includes the PTI Board step and the one on page 113 does not. The one with the PTI Board step matches the steps in paragraph 1384 on page 112 so it should be used. I am not sure why there was even a need to include the IANA Problem Resolution Process flow chart twice. I suggest deleting the first occurrence. That makes logical sense not only because it is incomplete but also because the last step in the CSC row of the IANA Customer Service Complaint Resolution Process for Naming Related Functions ends with IANA Problem Resolution Process (see next page) . | 7

  8. Document Document Review Timeline Timeline Review Process & Process &

  9. PTI Formation Documents Includes PTI Bylaws, Articles of Incorporation, and Conflict of Interest policy Term sheets reviewed with IOTF on calls 4 and 5 No objections to term sheets raised TIMING ICANN is drafting proposed PTI Bylaws and Articles of Incorporation to these term sheets, which can be shared next week. Month of May planned for review process. Public comment period during the month of June. PROCESS Need to develop process for community and ICANN to work together to iterate and finalize documents for public-comment posting Proposed Process: ICANN and Sidley legal teams collaborate to finalize documents review for adherence to PTI requirements and ICANN draft Bylaws. Any items raised by the community outside of the proposals and ICANN draft Bylaws will be flagged for IOTF discussion. Questions from legal teams will be raised to IOTF IOTF will provide responses to legal teams, consulting the relevant parties as appropriate The draft document will be sent to the CWG for review and feedback Feedback will be discussed with IOTF and incorporated as appropriate The final draft will be posted for a 30-day public comment period | 9

  10. ICANN-PTI Contract ICANN is drafting contract based on term sheet provided in Annex S Contract will be drafted to meet the requirements of the CWG with the ability for ICANN to sub-contract the performance of the number and protocol parameter services to PTI Additional input sources for the contract include: Annex E IANA contract provisions that should be carried over ICANN draft Bylaws Annex C Principles and criteria that should underpin decisions on the transition of NTIA stewardship for names functions TIMING: A draft of the contract and updated term sheet should be ready toward the end of May. Last part of May and all of June are planned for review process. Public comment period during the month of July. PROCESS: Need to develop process for community and ICANN to work together to iterate and finalize contract for public-comment posting Proposed Process: IOTF and Sidley legal team review draft simultaneously ICANN holds call with Sidley, IOTF to discuss/resolves issues Final draft shared with CWG for review and feedback Feedback will be discussed with IOTF and incorporated as appropriate Any sub-contracting provision will be reviewed with NRO and IETF The final draft will be posted for a 30-day public comment period | 10

  11. AOB & Closing Remarks

  12. Appendix Appendix

  13. List of implementation item requiring input from IOTF Category Items Priority Status 1. Approach for selection of PTI independent Board of Directors Define selection criteria for PTI independent Board of Directors PTI structure PTI governance documents ICANN-PTI Contract 1. 2. Completed Open PTI Board High 2. 1. 2. 3. 1. 2. 3. Open Open Open PTI* High CSC CSC formation High Open RZERC RZERC charter High Open 1. IANA Customer Service Complaint Resolution Process IANA Problem Resolution Process IANA Escalation Mechanisms 1. 2. Open Open Low 2. IANA IPR TBD Low Open * Consider and discuss sections 7 & 8 of Annex C from the CWG proposal during document development process | 13 For discussion

  14. IOTF Call Decision Log PTI Independent Board of Directors Initial Selections o Jonathan and Lise to serve as interim PTI independent directors assuming there are no issues around conflict and independence (Call #1, 21 March 2016) Ongoing Selections o NomCom will be the appointing body for PTI independent directors (Call #1, 21 March 2016) o Selection criteria will be provided by direct customers of IANA functions (the CSC) (Call #1, 21 March 2016) PTI Structure Operations of all 3 functions of Names, Numbers, and Protocol Parameters to move to PTI (Call #2, 25 March 2016) High-level PTI Conflict of Interest & Anonymous Reporting Policies No objections from IOTF (Call #4, 04 April 2016) Document Review Process & Timeline Agreement reached (Call #4, 04 April 2016) | 14

  15. Document Review Process & Timeline 1 2 3 IOTF reviews & agrees on high-level descriptions ICANN shares high-level descriptions with IOTF ICANN drafts full document 5 6 4 2 weeks 30 days ICANN analyzes comments, finalizes document & obtains Board approval ICANN finalizes & posts draft document for public comment OCs review & provide input on full document* | 15 For discussion

Related


More Related Content