| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | AA | AB | AC | AD | AE | AF | AG | AH | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | # for Reference purposes | Section from IANA Naming Functions Contract | Title | Contract Section Text | Notes from IFRT - Legal meeting, 25-Feb-2020. PENDING REVIEW AND NOT FINAL | Applicable Notes from Plenary Meetings | Applicable Notes from Subgroup Meetings | Questions for the CSC | Reference Material | Team Members Reviewing | Suggested Methods of Evaluation *please initial your comments | IFRT Request for Materials Required for Evaluation *please initial your comments | Findings/Notes *please initial your comments | Possible Outreach Questions *please initial your comments | Conclusion *please initial your comments | Final Text For Report | SCOPE Check | ||||||||||||||||||
2 | 1 | Contract Opening | This IANA Naming Function Contract (this “Contract”) is dated as of 30 September 2016 and is entered into by and between Internet Corporation for Assigned Names and Numbers, a California nonprofit public benefit corporation (“ICANN”) and Public Technical Identifiers, a California nonprofit public benefit corporation (the “Contractor”), and is effective as of the last date on which all of the conditions set out in ARTICLE II have been satisfied (the “Effective Date”). ICANN and Contractor may each be referred to herein individually as a “Party” and collectively as the “Parties.” WHEREAS, on 14 March 2014, the U.S. National Telecommunications and Information Administration (“NTIA”) announced the transition of NTIA’s stewardship role of key Internet domain name functions to the global multi-stakeholder community (the “Transition”); WHEREAS, following the Transition, ICANN will continue to serve as the Internet Assigned Numbers Authority (“IANA”) functions operator; and WHEREAS, ICANN and Contractor desire to enter into this Contract pursuant to which Contractor will serve as the operator for the IANA naming function after the Transition. NOW, THEREFORE, for good and valuable consideration, the sufficiency of which is hereby acknowledged, the Parties agree as follows: | The Cross Community Working Group (CGW) developed principles behind the contract during the IANA Stewardship Transition. CWG examined history and contracts with Department of Commerce and NTIA to ensure same level of IANA Functions performance were made. This is only 1 contract of several contracts with IANA Functions oversite. Opening identifies who this contract applies too | Cross Community Work Group (CWG) at https://community.icann.org/display/gnsocwgdtstwrdshp/CWG+to+Develop+an+IANA+Stewardship+Transition+Proposal+on+Naming+Related+Functions NTIA's involvement in the Stewardship Transition here: https://www.icann.org/resources/pages/transition-2014-03-23-en All PTI contracts found here: https://pti.icann.org/agreements | No findings required for this section | No findings required for this section | No findings required for this section | |||||||||||||||||||||||||||
3 | 2 | Article I, all sections | Definitions | See Contract for Definitions Section at: https://pti.icann.org/agreements | Standard Definition section: provides clarity and keeps contract short by establishing common language | N/A | No findings required for this section | No findings required for this section | No findings required for this section | ||||||||||||||||||||||||||
4 | 3 | Article II | Conditions Precedent | Condition Precedent. This Contract shall be effective as of the last date on which the following conditions have been satisfied: (a) the agreement between ICANN and the United States Department of Commerce (“DOC”), effective as of 01 October 2012 (including any extension thereof) has terminated or expired and (b) ICANN has accepted the responsibility to coordinate and administer the services that were previously provided thereunder. | N/A | No findings required for this section | No findings required for this section | No findings required for this section | |||||||||||||||||||||||||||
5 | 4 | Article III, all sections | Representations and Warranties | Section 3.1 ICANN’s Warranties. ICANN represents and warrants that (a) it has all necessary rights and powers to enter into and perform its obligations under this Contract; (b) the execution, delivery and performance of this Contract by ICANN has been duly authorized by all necessary corporate action and does not violate any applicable law to which ICANN is subject; and (c) the execution, delivery and performance of this Contract by ICANN do not (i) require a consent or approval under, or (ii) conflict with, result in any violation or breach of, constitute a default under, or accelerate any rights in favor of a third party under, any agreement between ICANN and a third party. Section 3.2 Contractor Warranties. Contractor represents and warrants that (a) it has all necessary rights and powers to enter into and perform its obligations under this Contract; (b) the execution, delivery and performance of this Contract by Contractor has been duly 5 authorized by all necessary corporate action and does not violate any applicable law to which Contractor is subject; and (c) the execution, delivery and performance of this Contract by Contractor do not (i) require a consent or approval under, or (ii) conflict with, result in any violation or breach of, constitute a default under, or accelerate of any rights in favor of a third party under, any agreement between Contractor and a third party. | Common to contracts. Each entity in the contract states they have the ability to enter into the contract and are warranting that they're going to perform the contract to the best of their ability and without violations | N/A | No findings required for this section | No findings required for this section | No findings required for this section | ||||||||||||||||||||||||||
6 | 5 | Article IV, Section 4.1 | Services and Requirements | Section 4.1 Designation. ICANN hereby designates Contractor as the operator of the IANA Naming Function, and authorizes Contractor to perform, the IANA Naming Function in accordance with the terms of this Contract (including the SOW). Without limiting the foregoing, ICANN hereby grants to Contractor, and Contractor hereby accepts, a worldwide, royalty-free, fully-paid right and license to the IANA Intellectual Property to the fullest extent permitted to be licensed to Contractor under the terms of the License Contract (including the right to further sublicense to the extent permitted in the License Contract). ICANN hereby authorizes Contractor to utilize any other rights and sublicensable licenses held by ICANN to the extent necessary or useful to perform the IANA Naming Function in accordance with the terms of this Contract (including the SOW). Contractor hereby accepts such designation, rights and licenses and agrees to perform the IANA Naming Function in accordance with the terms of this Contract (including the SOW). | Each entity states expectations. ICANN tells PGI that they are the entity that will perform this work. ICANN Bylaws obligate ICANN to set an entity to perform IANA Functions; have a contract with this entity. | No findings required for this section | No findings required for this section | No findings required for this section | |||||||||||||||||||||||||||
7 | 6 | Article IV, Section 4.2 | US Presence | · U.S. Presence. (a) Contractor shall be a wholly U.S. owned and operated corporation operating in one of the 50 states of the United States or District of Columbia; (ii) incorporated within the state of California, United States of America; and (iii) organized under the nonprofit public benefit corporation laws of the state of California. (b) Contractor shall perform the IANA Naming Function in the United States and possess and maintain, throughout the performance of this Contract, a physical address within the United States. Contractor must be able to demonstrate that all primary operations and systems will remain within the United States (including the District of Columbia). ICANN reserves the right to inspect the premises, systems, and processes of all security and operational components used for the performance of the IANA Naming Function. | PTI is required to maintain existence in the US; ICANN can inspect PTI’s offices. | No findings required for this section | No findings required for this section | No findings required for this section | |||||||||||||||||||||||||||
8 | 7 | Article IV, Section 4.3 (a) | Scope of the IANA Naming Function | Management of the DNS Root Zone (“Root Zone Management”) in accordance with the Statement of Work attached as Annex A to this Contract (“SOW”) | 4.3 Lays out main responsibilities in the subsections. PTI cannot change what services they want to perform. PTI must work with ICANN if PTI desires changes. This issue has yet to happen. PTI is a contractor to ICANN, not a decision maker on their own in relation to IANA Functions. | In IANA SERVICES OVERVIEW by Kim Davies, (https://community.icann.org/display/ifr/Webinar%3A+IANA+Overview+for+IFRT+-+24+January+2020+@17%3A00+UTC) PTI's root zone management is discussed 40 minutes into recording. | ‘Amendment No. 1 to IANA Naming Function Contract’ as of 07 May 2019 deleted Section 2, subsections (c) through (g) of the Annex A (=SOW) and replaced while also moving the Service Level Agreements (SLAs) to https://pti.icann.org/iana-naming-function-services-service-level-agreements | Amy: The SOW lays out service level agreements and definitions around each metric. Monthly reporting, as well as monthly oversite of these reports by the Customer Standing Committee (CSC) has verified that PTI has "met" these SLAs consistently. Changes to the SOW and the SLAs have been agreed up and overseen by the CSC, followed expected community consultations through Public Comments, and followed the Change Processes agreed up by ICANN, PTI and the CSC. | The IFRT finds that the SOW lays out service level agreements and definitions around each metric. Monthly reporting, as well as monthly oversight of these reports by the Customer Standing Committee (CSC), has verified that PTI has "met" these SLAs consistently. Changes to the SOW and the SLAs have been agreed up and overseen by the CSC, followed expected community consultations through Public Comments, and followed the Change Processes agreed up by ICANN, PTI and the CSC. | ||||||||||||||||||||||||||
9 | 8 | Article IV, Section 4.3 (b) | Scope of the IANA Naming Function | Scope of the IANA Naming Function Article IV, Section 4.3 (b) Management of the .INT top-level domain | In IANA SERVICES OVERVIEW by Kim Davies, (https://community.icann.org/display/ifr/Webinar%3A+IANA+Overview+for+IFRT+-+24+January+2020+@17%3A00+UTC) .int is discussed 1:07 minutes into recording. 1IFRT Plenary Meeting #18 IFRT PLENARY MEETING , 15 September 2020 Recommendation on intI. The wording of Rec 2 creates concerns that the Recommendation could: •suggest that .int domain should be treated like a gtld. This is not in the IFR’s scope •the IFRT’s concerns with .int are not substantive (agreed) and having a recommendation about it brings it into community focus and could make it seems more important then it is •unexpected outcomes....could easily be misinterpreted by community What Recommendation should convey: •IFRT is making an operational observation. •Operational suggestions can be dealt with internally by PTI without needing the Board to direct ICANN/PTI to do so •We want to draw attention to .int operational issues, without risking raising larger issues like policy of .intP Whether to Keep of Remove Rec Reasons to keep Recommendation: •If it isn’t a recommendation, there is no impetuous to get it done. •Allows the next IFR to ensure that PTI made operational changes as they need to judge execution of the Boardapproved recommendations •We actually do have a recommendation, we want PTI to make/update some operational housekeeping for .int •There are operational gaps that Kim Davies has pointed out •Kim Davies shared that PTI has refrained from making any operational changes to .int due to concerns that PTI could be perceived as going into policy; or that making changes would bring attention to .int and lead to community work that PTI did not have resources to follow or support. By making this a recommendation, it gives PTI a platform to move forward with said changes without concerns of negative fall-out from community Reasons to drop Recommendation but Keep the IFRT’s “Finding” statement •distinction here leaving it as a finding points out the issue is operational ambiguity or potential gap and operational processes, but the current Recommendation #2 text is framed in terms of identifying policy gaps. •As a finding we can draw attention to the operational issues without creating big challenges with thecommunity interpreting the Recommendation Reasons to keep original wording of FINDING •Recommendation #2 text is framed in terms of identifying policy Reasons to change wording of Finding •By stating that PTI’s operational ownership of .int is in direct conflict with Section 4.5 that PTI cannot be involved in policy setting, you have to make a recommendation to prevent this conflict. If we are dropping the Recommendation then we cannot believe this current finding’s statement •Section 4.5 starts out by saying “Contractor shall ensure that its staff performing the IANA Naming Function do not publicly initiate, advance or advocate any policy development related to the IANA Naming Function.” HOWEVER it goes on to say, “Contractor’s staff may ..... (ii) request guidance or clarification as necessary for the performance of the IANA Naming Function, and (iii) publish, contribute to or comment on any document related to ongoing policy discussions, provided that, in the case of clause (iii), the primary purpose of such publication, contribution or commentary is to supply relevant IANA Naming Function experience and insight.” o The later part of this section would allow PTI to request the community start policy development if PTI felt a policy was necessary, etc. in order for PTI to make operational changes we suggest in the finding. o in the abstract, by identifying policy areas of concern to the ICANN Board, and if the ICANN Board creates a mandate to perform a policy review, PTI has facilitated it but this section allows that o Statement by KIM from PTI: The difference between PTI handling .int operations comparedto all of PTI’s responsibilities is that for .int PTI would probably need to take direct responsibility for addressing an issue, whereas in the other areas of our work, we rely upon other organizations to take the lead in structuring policy engagement. But PTI could assist in 5“stage managing” the start of policy development. For example, PTI might convene a panel of our customers; engage some 3rd party assistance; build an ad hoc consortium to talk about the policy or to bounce a draft policy off. Then PTI would take that to the community for consideration, and implement the final proposal. So I think that's how I would look at navigating this in a way that doesn't conflict with section 4.5 where we are not developing policy for ourselves. PTI would just need to take a unique approach, making sure that thepolicy is properly reviewed by the Community •Just because a declaring out right that there's a conflict here is going to invite people to create mechanisms and it mechanisms for creating new policy and I'm not sure that's either borne out by the situation or a good idea. FINAL DECISIONS1. .int Recommendation was removed. In the Findings section , found within the Initial Draft under Bylaws 18.3.(c), then page 16 where Article IV, Section 4.3 Scope of the IANA Naming Function is listed, was re-written to read | To watch the meeting recording: https://community.icann.org/display/ifr/Subgroup+Call%3A+.int | https://www.iana.org/domains/int | Tomslin | [Tomslin]Reach out to current registrants with questions regarding PTI's performance | List of current registrants | [Tomslin] The team found that PTI manages the .INT TLD as required by the contract. However, the team also found that there is no defined community in ICANN where policy discussion and development on .INT can be had. PTI has therefore had to manage the policies of the .INT but that conflicts with section 4.5 of the contract, which requires separation of policy development roles from operational roles of IANA naming functions. The IFRT suggests that some clarity should be made in the contract to address this conflict. Furthermore, the team found that there is a challenge validating .INT registrants data and accuracy in the absence of a renewal process for the domains. Reviewed and Accepted during 21 july 2020 Plenary Meeting | The IFRT finds that PTI manages the .INT TLD as required by the contract. However, the team also found that there is no defined community in ICANN where policy discussion and development on .INT can be had. PTI has therefore had to manage the policies of the .INT but that conflicts with section 4.5 of the contract, which requires separation of policy development roles from operational roles of IANA naming functions. The IFRT suggests that some clarity should be made in the contract to address this conflict. Furthermore, the team found that there is a challenge validating .INT registrants data and accuracy. A renewal process for the domains could improve this situation. | |||||||||||||||||||||||
10 | 9 | Article IV, Section 4.3 (c) | Scope of the IANA Naming Function | Scope of the IANA Naming Function Article IV, Section 4.3 (c) Maintenance of a repository of internationalized domain name tables and label generation rulesets | In IANA SERVICES OVERVIEW by Kim Davies, (https://community.icann.org/display/ifr/Webinar%3A+IANA+Overview+for+IFRT+-+24+January+2020+@17%3A00+UTC) IDN Tables are discussed 1:09 minutes into recording. | https://www.iana.org/domains/idn-tables | Tomslin | [Tomslin]Review the IDN repository and the procedures for the IDN Repository | None | [Tomslin]A repository of IDN names is being maintained. | None | [Tomslin]PTI maintains a repository of IDN names as required by the contract. The repository can be found at https://www.iana.org/domains/idn-tables Reviewed and Accepted during 21 july 2020 Plenary Meeting | The IFRT finds that PTI maintains a repository of IDN names as required by the contract. The repository can be found at https://www.iana.org/domains/idn-tables. | ||||||||||||||||||||||
11 | 10 | Article IV, Section 4.3 (d) | Scope of the IANA Naming Function | Scope of the IANA Naming Function Article IV, Section 4.3 (d) Provision of other services and implementation of modifications in performance of the IANA Naming Function, in each case upon ICANN’s request and in conformance with applicable policies and procedures. | IFRT#7 [Kim Davies]: Example is the established procedure for making formal changes to SLAs, and this process has been utilized and well documented. | 1. Does the CSC believe there are processes to address each area where performance of the IANA Naming functions might require changes? ANSWER: Yes. 2. For modification processes that do exist (relevant to the CSC is the SLA change procedure) are you satisfied with the procedure? Has the procedure been invoked and was it successful? ANSWER: When it was determined that SLAs needed to be modified, it took a long time to create the SLA Change Procedure. We reported about the process on our CSC monthly report. Now that there is a procedure, making the SLA changes have commenced. | The CSC, ICANN & PTI utilized the SLA Amendment Process (https://www.icann.org/en/system/files/files/iana-naming-function-sla-amendment-process-28mar19-en.pdf) to make three sets of SLA changes: 1. Technical Check SLA changes implemented 01 July 2019 2. new LGR SLAs implemented 01 January 2020 3. currently pending are new/changes to ccTLD creation/transfer SLAs PTI FY21 - FY24 Strategic Plan webinar, Service Delivery is discussed 18min in https://icann.zoom.us/rec/play/7pUuJe-sqzk3G4DBsASDVvR6W9W9Kfqs0ykd-KFcnU-2U3AFMFr0ZuFBNuVfCHlhqY88Tlio0WeNEuXf?continueMode=true | Suzanne | Amy: ICANN confirmed that this contract requirement has been adhered to by PTI. An example is changing PTI’s Service Level Agreements (SLAs): working with ICANN and the CSC, PTI developed a SLA Change process, and adhered to it when changes were made to 3 sets of SLAs. | The IFRT finds that ICANN has confirmed to the review team that this contract requirement has been adhered to by PTI. An example is changing PTI’s Service Level Agreements (SLAs): working with ICANN and the CSC, PTI developed a SLA Change process, and adhered to it when changes were made to three (3) sets of SLAs. | 18.3.d, 18.3.i | ||||||||||||||||||||||||
12 | 11 | Article IV, Section 4.4 | Performance of IANA Naming Function | Article IV, Section 4.4 Performance of IANA Naming Function Contractor shall respect the diversity of customers of the IANA Naming Function and shall provide service to its customers in conformance with prevailing technical norms, and in support of the global security, stability and resilience of the DNS. If a customer’s receipt of services is based on a contract between such customer and ICANN, Contractor shall continue to provide services to such customer notwithstanding any on-going or anticipated contractual disputes between ICANN and such customer. | How PTI should do their work: that their work is done in a stable and secure manner in accrodance with statement of work they are meeting; following policies developed thru ICANN's PDPs; PTI's performance obligation. Naming function service should be equal with Number function. And next, customers of any IANA function perfromed by PTI will all be treated equally. No customer is entitled for more or different treatment from PTI & ICANN. Diversity to be respected (ICANN concerns over diversity is self imposed) | IFRT#7 [Kim Davies]: Statistical, machine readable data is available, but no "open transaction data" since most transactions are confidential. Also, there are different SLAs for different customer groups. The SLAs track measurements across all th ereserve management functions (see SLA Dashboard at ) and this dat is available for machine readable download without PTI needing to disclose anything. Part of analysis could be PTI describing approach to working with customers and overall work process. If IFRT wants more data, submit a request to PTI and staff will determine how to respond. | The CSC Reports: https://www.icann.org/en/csc/reports recommend watching this webinar: PTI FY21 - FY24 Strategic Plan webinar https://icann.zoom.us/rec/play/7pUuJe-sqzk3G4DBsASDVvR6W9W9Kfqs0ykd-KFcnU-2U3AFMFr0ZuFBNuVfCHlhqY88Tlio0WeNEuXf?continueMode=true | Patrik | Look at the result of the CSC review, ensure the SLA's are met, compare with the scope (Article IV, Section 4.3(d)). Ask PTI for post mortem for N latest issues that did fall outside of the SLA, why that happened and what has changed to make things better next time. [Tomslin] Something we could also consider is, to understand why PTI has different SLAs for different groups of customers, and if there is fairness in that difference. | PTI has shown that all customers are handled according to the PTI Service Level Agreement that applies. No complaints have surfaced with regard to inequal treatment, or concern that issues between the customer and other ICANN departments have had a bearing on how their IANA requests are processed, which was confirmed by the CSC as well. This section also references PTI's performance obligations which are monitored through monthly SLA reports, and annual audits such as SOC2 and SOC3. ICANN org has indicated its satisfaction at PTI's performance as reflected by these reports. Patrik signed off on Finding. | The IFRT finds that PTI has shown that all customers are handled according to the PTI Service Level Agreement that applies. No complaints have surfaced with regard to unequal treatment, or concern that issues between the customer and other ICANN departments have had a bearing on how their IANA requests are processed, which was confirmed by the CSC as well. This section also references PTI's performance obligations which are monitored through monthly SLA reports, and annual audits such as SOC2 and SOC3. ICANN org has indicated its satisfaction at PTI's performance as reflected by these reports. | 18.3.a | |||||||||||||||||||||||
13 | 12 | Article IV, Section 4.5 | Separation of Policy Development and Operational Roles | Contractor shall ensure that its staff performing the IANA Naming Function do not publicly initiate, advance or advocate any policy development related to the IANA Naming Function. Notwithstanding the foregoing, Contractor’s staff may (i) respond to requests for information requested by Interested and Affected Parties, and, at Contractor’s volition, provide objective information to such customers, in each case, to inform ongoing policy discussions, (ii) request guidance or clarification as necessary for the performance of the IANA Naming Function, and (iii) publish, contribute to or comment on any document related to ongoing policy discussions, provided that, in the case of clause (iii), the primary purpose of such publication, contribution or commentary is to supply relevant IANA Naming Function experience and insight. | This section reflects an issue of importance to the US government in 2012: clear separation between policy development and operational roles. The US was bidding for an entity to take on the IANA Functions and the customers of IANA function asked for this to be maintained in post transition work. The people who perform the Naming Function are not to be the same people setting the policies. The Naming function team is to inform policy making, but not involved in setting that policy. ICANN leaves policy development to community and recommendations go to ICANN Board, and Board directs ICANN to direct PTI to follow that policy. | IFRT #7: [Peter] One approach would require a great level of detail in research but needs some clarification as to intent of the section. [Amy can assist with pulling research but team needs to determine level of effort] [Kim] Naming policies must start in ccNSO or GNSO, so you can consult with these groups about PTI's role in policy. [Peter]: who sets policy for .int though? Asking ccNSO/GNSO is one input, but still could dive into archives (go through PDP related emails to see how PTI interacted with PDP team). We should document our decision about our determined evaluation method...... [Steve C] contract section is separating PTI's participation vs. PTI's attempt to control policy....ask ccNSO/GNSO if PTI had "appropriate" level of interaction with PDP teams. TEAM DECIDED: to go back to ccNSO/GNSO for opinion | only ccNSO and GNSO can make policies applicable to Naming Functions In a PTI Budget & Strategic Plan webinar, this is discussed at different points, but a community question specifically about this is asked at 41mins in https://icann.zoom.us/rec/play/7pUuJe-sqzk3G4DBsASDVvR6W9W9Kfqs0ykd-KFcnU-2U3AFMFr0ZuFBNuVfCHlhqY88Tlio0WeNEuXf?continueMode=true | Peter: will speak to ccNSO J.C.: will speak to GNSO James can give support to J.C. | consultation with GNSO and ccNSO. Ask ccNSO/GNSO if PTI attempted to influence policy decision making...did they appropriately collaborate/respond to PDP team or try to change the policy outcome? | Amy; As per this requirement, there is clear separation between policy development and the operational role that PTI plays. ICANN leaves policy development to the community. PTI has always been responsive to informing policy makers with full cooperation, and to-date there have been no concerns that PTI has tried persuading or become involved in policy decisions. | The IFRT finds that this clause has been met and in its review and discussions has not found any evidence that PTI staff are engaging in any policy development activities outside of their scope. | 18.3.b | |||||||||||||||||||||||
14 | 13 | Article IV, Section 4.6 | User Instructions | Contractor shall, in collaboration with all Interested and Affected Parties, maintain user instructions for the IANA Naming Function, including technical requirements. Contractor shall post such instructions at iana.org (“IANA Website”). | How PTI is expected to interact and take on responsiblities for our stakeholders. Some items in this section came from the legacy contracts previously mentioned, but some were from the 2014 Framework of Interpretation and Delegation of ccTLDs. This work on ccTLs changed a lot of nomenclautre used, and changed how we view the different roles in the managment of ccTLDs. This carried over to the governing of PTI which needs to respect the work of the Framework of Interpretation Working Group (FOIWG). This section says PTI is responsible for followng current registration policies. PTI also must be prepared for transfering the IANA Functions to another entity if required of PTI to do so. | IFRT#7 [Kim]: carry over language from NTA contract. Very early discussions about whether PTI was allowed to publish documentation at all, so this section allows PTI to publish. See URLs under "reference material" [Christian]: is there access to a test system [Kim]: no user facing test system. Some documentation is not published if it is too technical and for PTI side [Christian]: not a tld manager, so how would I evaluate it? [Kim]: very little documention on how to operate the system...since system is fairly straight forward. The documentation provides overview of IANA functions, policies and procedures. Does direct user as to what documentation is required for submitting to system. [Fred - Kim] discuss that clear policy stated on website is same from post-transition with no updates reflecting new proposals | For recording of this meeting: https://community.icann.org/pages/viewpage.action?pageId=138969340 1. Why this clause is in the contract NTIA would not allow IANA to publish user instructions, amongst other things, since there was no provision in the contract regarding publishing this. ICANN ensured this made it into the 2013 contract revisions. Rick: reviewed materials in advance. Feels they are consistent with IANA’s processes and meet contract requirement. 2. Discussion about how procedures vs. policy is represented in the user guides Fred: some policies not reflected in guides; in IFRT report wants to list what is not covered in user documentation. Policy root zone changes, how IANA manages it, needs more coverage. Kim: https://www.iana.org/help/obtaining-consent Process is current. Will change the documentation if the process changes due to policy changes. Peter: IFRT shouldn’t be reviewing the detail of the document content itself, but at the topics and structure of offering documentation. Sees difference between Eligible top level domain streams document is not a “process” but “information”; normative vs. informative. Procedures for community involvement in IANA related policies. Kim: IANA doesn’t set policy; just set operations so concern over normative vs. informative documentation may not hold value. Current documentation seems useful for customers on how IANA works. How do we drive documentation? – user demand; operational changes. Is your question really what kind of consultation do we do with customers when we change our operational procedures? There is no change process per se (ie. Decision tree): We discuss internally and determine who needs to be informed, vs. who needs to consent: typically it is RZERC, ICANN Board of Directors; impacts on publication of RZM- involve the RZM which is Verisign and Root Zone Operators. If no external impacts on IANA’s partners, then we dicsuss if it’s a material impact on customers and we would go to ccNSO, GNSO. Technical Workshop DNS OZARK other options. Contractual change?- then there is specific process. Incremental minor changes may not need any consultation such as requests to add support for addl algorithm types in root zone and we only worked with Verisign on this. Peter: acknowledges Micromanagement vs processes distinction. Fred: we are discussing better policy description that could be outside of user instruction, but also referenced within user instructions so that when reading user instructions it tells you what policy each point derived from. Kim: “policy” – IANA firmlhy doesn’t set policy. We are implementing policy and concerns of starting to quote policy within user instructions. Other groups have very specific definitions of policy…just using this word could cause concerns about IANA getting involved in policy. Does agree we lack well stated policies. IANA derives the “policy” we follow from different sources. Often the policy is vague but IANA still has to figure out how to operationalize them. Draft Statement of IFRT’s Findings/Recommendations The current text in things posted on (cite reference material) meets requirements of Article IV, Section 4.6: User Instructions. However the review team notes the content contains mix of instructions & policy and team [may] suggest that IANA works on separating content to provide more pure form of instruction and in next iteration of such content to allows more amateur users clearer instructions for utilizing IANA website. 3. Frequency and process for reviewing and updating the user guides Fred: frequency of reviewing protocols? Regular cadence might be good process. Kim: have annual technical discussions with Verisign. Fred: community participation and what is user instructions to use RZM and what is policy and how it should evolve regarding information that needs to be included in user instructions? Need to define. | Framework of Interpretation and Delegation of ccTLDs (FOIWG): https://ccnso.icann.org/en/workinggroups/foiwg.htm Root Zone Management: User Instructions and Guides at https://www.iana.org/domains/root/help IANA SERVICES OVERVIEW by Kim Davies, SOC2 audit of processes is discussed at 13min in https://community.icann.org/display/ifr/Webinar%3A+IANA+Overview+for+IFRT+-+24+January+2020+@17%3A00+UTC | Fred [has access to PTI systems] | Fred has direct expience with PTI systems. Option: Kim can give system demonstration if requested. | Amy: PTI has published user instructions for IANA services and systems on iann.org. IFRT members have recommendations on increasing the utility of the current instruction set. | The IFRT finds that PTI has published user instructions for IANA services and systems on iann.org. IFRT members have recommendations on increasing the utility of the current instruction set. | 18.3.a | ||||||||||||||||||||||
15 | 14 | Article IV, Section 4.7 | Responsibility and Respect for Stakeholders | Contractor shall apply the policies for the Root Zone Management component of the IANA Naming Function that have been defined, or after the date of this Contract are further defined, by (a) the Generic Names Supporting Organization (“GNSO”), as appropriate under ICANN’s Bylaws, (b) the Country Code Names Supporting Organization (“ccNSO”), as appropriate under ICANN’s Bylaws, and (c) RFC 1591: /Domain Name System Structure and Delegation/ (“RFC 1591”) as interpreted by the Framework of Interpretation of Current Policies and Guidelines Pertaining to the Delegation and Redelegation of Country-Code Top Level Domain Names, dated October 2014 (“FOI”). In addition to these policies, Contractor shall, where applicable, consult the 2005 Governmental Advisory Committee Principles and Guidelines for the Delegation and Administration of Country Code Top Level Domains (“GAC 2005 ccTLD Principles”). Contractor shall publish documentation pertaining to the implementation of these policies and principles on the IANA Website. | see above | IFRT#7: TEAM DECISION: Can be bundled with Article IV, Section 4.5: Separation of Policy Development and Operational Roles | www.iana.org/domains/root | Peter: will speak to ccNSO J.C.: will speak to GNSO James can give support | Amy: PTI has complied with all policies regarding the IANA Naming Service functions. | The IFRT finds that PTI has complied with all policies regarding the IANA Naming Service functions. | 18.3.a | ||||||||||||||||||||||||
16 | 15 | Article IV, Section 4.8 all | Management of the .INT TLD | (a) Contractor shall operate the .INT TLD within the current registration policies for the .INT TLD. (b) Upon designation of a successor registry by ICANN, if any, Contractor shall cooperate with ICANN to facilitate the smooth transition of operation of the .INT TLD. Such cooperation shall, at a minimum, include timely transfer to the successor registry of the then-current top-level domain registration data. | PTI is responsible for followng current registration policies in managing .int. PTI also must be pepared for transfering the .int registry services to another entity if required of PTI to do so. | IFRT#7 [Kim]: about 200-210 delegations. Strict eligibility criterial, only for inter-governmental treaty organizations. Low churn, if we remove ineligible requests, we have a dozen requests a year. Low transaction rate. [Fred]: is it managed through a separate registry system or RCM or email.... [Kim]: manual...we do use ticketing system to capture request but no automation. We will not be building a portal for 12 applications a year. There is a manual formal process with business system steps. Automated testing though, same system testing root zone. Unsigned zone goes through an automated signing process and is published. [Patrik]: Peter can look at peter.int | To watch the meeting recording: https://community.icann.org/display/ifr/Subgroup+Call%3A+.int | https://www.iana.org/domains/int | Peter & James | Option: Kim can hold webinar on this topic if requested | Amy: PTI has adhered to all registration policies in managing .int. The PTI Transition plan applies to transition .int if necessary. Additional comments on .int can be found for Article IV, Section 4.3 (b): Scope of the IANA Naming Function which merely states: Management of the .INT top-level domain”. | The IFRT finds that PTI has adhered to all registration policies in managing .int. The PTI Transition plan applies to transition .int if necessary. Additional comments on .int can be found for Article IV, Section 4.3 (b): Scope of the IANA Naming Function which merely states: Management of the .INT top-level domain”. | 18.3.b | ||||||||||||||||||||||
17 | 16 | Article IV, Section 4.9 (a) | General Manager; Key Personnel. | (a) Contractor shall provide trained, knowledgeable technical personnel according to the requirements of this Contract, including the following key personnel: a General Manager, a Director of Security and a Conflict of Interest Officer (“Key Personnel”). All Contractor personnel who interface with ICANN must have excellent oral and written communication skills. "Excellent oral and written communication skills" is defined as the capability to converse fluently, communicate effectively, and write intelligibly in the English language. (b) The Conflict of Interest Officer shall be responsible for ensuring the Contractor is in compliance with Contractor’s internal and external conflict of interest rules and procedures. (c) The General Manager of Contractor shall organize, plan, direct, staff, and coordinate the overall performance of the IANA Naming Function; manage contract and subcontract activities as the authorized interface with ICANN and ensure compliance with applicable rules and regulations. The General Manager of Contractor shall be responsible for the overall performance of Contractor under this Contract and shall meet and confer with ICANN (including the Customer Standing Committee (“CSC”) and IANA Function Review teams (“IFRT”), as such terms are used in ICANN’s Bylaws) regarding the status of specific Contractor activities and problems, issues, or conflicts requiring resolution. The General Manager of Contractor must possess the following skills: (i) demonstrated communication skills with all levels of management; (ii) capability to negotiate and make binding decisions for Contractor (subject to any requirements of Contractor’s Bylaws and the authority delegated to such person by the Contractor’s Board of Directors (“PTI Board”)); (iii) extensive experience and proven expertise in managing similar multi-task agreements of this type and complexity; (iv) extensive experience supervising personnel; and (v) a thorough understanding and knowledge of the principles and methodologies associated with operations management and contract management. (d) Contractor shall obtain the approval of ICANN, after consultation with the PTI Board, prior to making Key Personnel substitutions. Replacements for Key Personnel must possess qualifications reasonably equal to or exceeding the qualifications of the personnel being replaced, unless an exception is approved by ICANN. | Dept of Commerce contract had specific roles specified: CWG wanted those roles to carry over, like: Conflict of Interest Officer, etc. | IANA SERVICES OVERVIEW by Kim Davies: 18 minutes in discusses team https://community.icann.org/display/ifr/Webinar%3A+IANA+Overview+for+IFRT+-+24+January+2020+@17%3A00+UTC | Kaili | This section of the contract mirrors the original IANA Service's Dept of Commerce contract, which listed specific roles and titles. Today, while PTI does not have all specific titles listed, the responsibilities under said contract titles are addressed and handled by PTI staff. There has been no community feedback suggesting any functional gaps within PTI. The IFRT believes that PTI has meant the intention behind this contract section and suggests that this section would benefit from being written to remove specific Title requirements and instead focus on PTI Management's responsibility to staff for optimal performance. Kaili OKed this draft 7/23/20 | The IFRT finds that this section of the contract mirrors the original IANA Service's Dept of Commerce contract, which listed specific roles and titles. Today, while PTI does not have all specific titles listed, the responsibilities under said contract titles are addressed and handled by PTI staff. There has been no community feedback suggesting any functional gaps within PTI. The IFRT believes that PTI has meet the intention behind this contract section and suggests that this section would benefit from being re-written to remove specific Title requirements and instead focus on PTI Management's responsibility to staff for optimal performance. | 18.3.b | |||||||||||||||||||||||||
18 | 17 | Article IV, Section 4.10 all | Inspection Of All Deliverables And Reports Before Publication. | (a) Prior to publication or posting of reports and other deliverables anticipated under this Contract on a template that has not been previously approved by ICANN, Contractor shall obtain approval from ICANN for such template, which will not be unreasonably withheld. Any deficiencies identified by ICANN shall be corrected by Contractor and resubmitted to ICANN within 10 business days after Contractor’s receipt of notice of such deficiency. (b) ICANN reserves the right to inspect the premises, systems and processes of all security and operational components used for the performance of all the requirements and obligations set forth in this Contract. | ICANN can inspect PTI's deliverables. SLA between ICANN and PTI for back-and-forth decision making, so each responds to the other in a timely manner. ICANN has to abide by these rules too. | IFRT#7: [Fred] to Kim, can you provide a report regarding this? [Kim] not sure what a report would entail but we could make an assertion. Private communications between ICANN & PTI. Maybe we have a representative of ICANN & PTI attest this is being met. TEAM DECISION that attestation from PTI & ICANN would fulfill this | Tomslin | get Attestation from PTI/ICANN | [Tomslin] Request for attestation sent to ICANN and PTI [UPDATE] ICANN and PTI agreed verbal attestation should suffice. | [Tomslin] The team finds that ICANN inspects PTI's deliverables and reports as is required by the contract. Reviewed and Accepted during 21 july 2020 Plenary Meeting | The IFRT finds that ICANN inspects PTI's deliverables and reports as is required by the contract. | 18.3.b | |||||||||||||||||||||||
19 | 18 | Article V | Performance | Notes to apply to all sections of Article V: Performance below. High level statements of how ICANN expects PTI to do their work. Keep in mind that there are other contracts between ICANN and PTI, the IANA Services Agreement is a broad contract that obligates ICANN to provide PTI with the resources necessary to comply with all contracts, such as the Naming Functions contract. These other contracts are out-of-scope, but if the IFRT finds deficiencies which you believe are linked to other contracts, you can write a recommendation requesting to review those contracts | No findings required for this section | ||||||||||||||||||||||||||||||
20 | 19 | Article V, Section 5.1 all | Constructive Working Relationship | Contractor shall use commercially reasonable efforts to maintain a constructive working relationship with ICANN, the root zone maintainer and all Interested and Affected Parties to ensure quality and satisfactory performance of the IANA Naming Function. | see above | IFRT#7: [James] involve Becky as the PTI finance part of this | Tomslin & Fred | Attestation from Amy, Becky (Finance), Kim | [Tomslin] Request for attestation sent to PTI and ICANN | [Tomslin] ICANN and PTI agree that verbal attestation should suffice | [Tomslin] The team finds that PTI has a constructive working relationship with ICANN Reviewed and Accepted during 21 july 2020 Plenary Meeting | The IFRT finds that PTI has a constructive working relationship with ICANN. | 18.3.b | ||||||||||||||||||||||
21 | 20 | Article V, Section 5.2 (a) | Continuity of Operations | Either ICANN or the Contractor shall provide, at a minimum, redundant sites in at least two geographically dispersed sites within the United States as well as multiple resilient communication paths to customers to ensure continuation of the IANA Naming Function in the event of cyber or physical attacks, emergencies, or natural disasters. | see above | IANA SERVICES OVERVIEW by Kim Davies, Security among other Audits discussed at 13min in https://community.icann.org/display/ifr/Webinar%3A+IANA+Overview+for+IFRT+-+24+January+2020+@17%3A00+UTC | Tomslin & James | [Tomslin] The team finds that as required by the contract, PTI and ICANN provide geographically separated sites within the United States for the performance of IANA Naming Functions, with multiple resilient communication paths to customers. Reviewed and Accepted during 21 july 2020 Plenary Meeting | The IFRT finds that as required by the contract, PTI and ICANN provide geographically separated sites within the United States for the performance of IANA Naming Functions, with multiple resilient communication paths to customers. | 18.3.b | |||||||||||||||||||||||||
22 | 21 | Article V, Section 5.2 (b) | Continuity of Operations | Contractor shall collaborate with ICANN to develop and implement a Contingency and Continuity of Operations Plan (“CCOP”) for the IANA Naming Function. Contractor in collaboration with ICANN shall from time to time update and annually test the CCOP as necessary to maintain the security and stability of the IANA Naming Function. The CCOP shall include details on plans for continuation of the IANA Naming Function in the event of cyber or physical attacks, emergencies, or natural disasters. Contractor shall submit the CCOP to ICANN after each update and publish on the IANA Website a report documenting the outcomes of the CCOP tests within 90 calendar days of the annual test. | ICANN requires PTI to have a business continuity plan. | CCOP created in 2016. Latest version is 6.0 as of January 2017. This is not a public document. IANA SERVICES OVERVIEW by Kim Davies, Security among other Audits discussed at 13min in https://community.icann.org/display/ifr/Webinar%3A+IANA+Overview+for+IFRT+-+24+January+2020+@17%3A00+UTC PTI FY21 - FY24 Strategic Plan webinar, Security is discussed 14min in https://icann.zoom.us/rec/play/7pUuJe-sqzk3G4DBsASDVvR6W9W9Kfqs0ykd-KFcnU-2U3AFMFr0ZuFBNuVfCHlhqY88Tlio0WeNEuXf?continueMode=true | Tomslin & James | Request to PTI for CCOP | [Tomslin] The team finds that as required by the contract, PTI has developed a Contingency and Continuity of Operations Plan (CCOP) document, created in 2016 and the document is regularly updated. The team also finds that while the contract requires annual testing of the Contingency and Continuity of Operations Plan and the report be published publicly on the IANA website, only the 2019 report of these tests is available at https://www.iana.org/reports. The team recommends that PTI publishes all previous test reports since 2016 and should continue to publish future reports within 90 calendar days of the annual test, as required by the contract. Reviewed and Accepted during 21 july 2020 Plenary Meeting | The IFRT finds that as required by the contract, PTI has developed a Contingency and Continuity of Operations Plan (CCOP) document, created in 2016 and the document is regularly updated. The team also finds that while the contract requires annual testing of the Contingency and Continuity of Operations Plan and the report be published publicly on the IANA website, only the 2019 report of these tests is available at https://www.iana.org/reports. The team recommends that PTI publishes all previous test reports since 2016 and should continue to publish future reports within 90 calendar days of the annual test, as required by the contract. | 18.3.b | ||||||||||||||||||||||||
23 | 22 | Article V, Section 5.3 all | Performance Exclusions | (a) Contractor is not authorized to perform the services performed by the root zone maintainer, as such services are contemplated by the RZMA, unless authorized by ICANN. (b) Contractor shall not make changes in the policies and procedures developed by the relevant entities associated with the performance of the IANA Naming Function. (c) The performance of the IANA Naming Function shall not be, in any manner, predicated upon or conditioned by Contractor on the existence or entry into any contract, agreement or negotiation between Contractor and any TLD registry operator or any other third party. Compliance with this Section must be consistent with the SOW. | There are certain areas where PTI is not to perform. The RZMA Agreement - provisions for ICANN to perform, and not for the IANA Functions Operator. This is saying, just because this contract references responsibilities from other contracts, it does not mean PTI is responsible for the scope of that referenced contract. Contractor cannot make changes to process/procedures on their own. | IFRT#7: [Fred] for Root Zone operator would we request attestation from Verisign ? or? [Kim]: section is here to preserve the status quo in the transition when there was a separation of funcitons. Shows that this is at discretion of ICANN and not PTI. [Peter] related to lines 14/15 with PTI not being allowed to engage in policy making. New ideas about distributing the root zone, but it's not PTI engaging in this, it is ICANN as the root zone operator responsible. Believes section could be reworded. [Fred]: Root zone ceremonies do signatures...controlled by Verisign. What are the technical interfaces between ICANN & Verisign? [Kim]: 2 technical interfaces: (1) EPP for exchanging the deltas between unsigned root zone additions and (2) KSR-SKR Exchange where Verisign transmists to PTI via an API unsigned ZSSK and PTI sends back signatures. There are operational systems for interface and interaction. RZMA is detailed regarding this which has clear separation of roles documented. [Fred]: does the current architecture of the systems fulfill part of this section. | PTI FY21 - FY24 Strategic Plan webinar, Trust is discussed 7min in https://icann.zoom.us/rec/play/7pUuJe-sqzk3G4DBsASDVvR6W9W9Kfqs0ykd-KFcnU-2U3AFMFr0ZuFBNuVfCHlhqY88Tlio0WeNEuXf?continueMode=true | Christian Dawson | item a: attestation from Verisign and would architecture of systems fulfilll this | Amy: I believe that this section mirrors sections and findings already mentioned above, and can reference these sections. | The IFRT finds that this section has been fulfilled by PTI. | 18.3.b | |||||||||||||||||||||||
24 | 23 | Article VI | Transparency of Decision-Making | Notes apply to all of Section VI: Transparencey of Decision-Making below. Section about levels of information that PTI must make public for sake of their customers and to show transparencey in decision making. | The IFRT finds that PTI operated with an appropriate level of transparency in its decision making. | ||||||||||||||||||||||||||||||
25 | 24 | Article VI, Section 6.1 (a) | Transparency | To enhance consistency, predictability and integrity in Contractor’s decision-making related to the IANA Naming Function, Contractor shall: (a) Publish reports pursuant to ARTICLE VII of this Contract and Section 3 of the SOW. | see above | Article VII Reporting is: 1. The monthly audit report on the root zone file which is published according to the contract at: www.iana.org/performance/root-audit 2. The CSC reports which are published according to the contract at: https://www.iana.org/performance/csc-reports SOW Section 3 Reporting is: 1. Above mentioned CSC reports 2. The online "dashboard" maintained and updated at: https://sle-dashboard.iana.org/ 3. Annual Customer Survey which is published at: Annual Customer Surveys 2019: https://www.iana.org/reports/2019/customer-survey-20191210.pdf 2018: https://www.iana.org/reports/2018/customer-survey-20181206.pdf 2017: https://www.iana.org/reports/2018/customer-survey-20180118.pdf 2016: https://www.iana.org/reports/2017/customer-survey-20170111.pdf 2015: https://www.iana.org/reports/2015/customer-survey-20151115.pdf 2014: https://www.iana.org/reports/2014/customer-survey-20141217.pdf 2013: https://www.iana.org/reports/2013/customer-survey-20131210.pdf IANA SERVICES OVERVIEW by Kim Davies, Performance Reporting: 27min https://community.icann.org/display/ifr/Webinar%3A+IANA+Overview+for+IFRT+-+24+January+2020+@17%3A00+UTC PTI FY21 - FY24 Strategic Plan webinar, Trust is discussed 7min in https://icann.zoom.us/rec/play/7pUuJe-sqzk3G4DBsASDVvR6W9W9Kfqs0ykd-KFcnU-2U3AFMFr0ZuFBNuVfCHlhqY88Tlio0WeNEuXf?continueMode=true | Kristian Ørmen | KØ: I'm looking at all the reference material and the text in the contract | KØ: In the contract section 7,1 it states: The relevant policies under which the changes are made shall be noted within each monthly report. I don't see this noted in the reports. KØ: i find it odd that the dashboard is in Beta. For me Beta means that it's not ready Amy: PTI has removed the "BETA" label on the dashboard | Amy: this section refers to Article VII Reporting which consists of: 1. The monthly audit report on the root zone file which is published according to the contract at: www.iana.org/performance/root-audit 2. The CSC reports which are published according to the contract at: https://www.iana.org/performance/csc-reports PTI has met this requirement | The IFRT finds that via the monthly audit report on the root zone file, which is published according to the contract at: www.iana.org/performance/root-audit, and the CSC reports, which are published according to the contract at: https://www.iana.org/performance/csc-reports, PTI has met this requirement. | 18.3.d | |||||||||||||||||||||||
26 | 25 | Article VI, Section 6.1 (b) | Transparency | Make public all decisions of the PTI Board relating to the IANA Naming Function, unless, upon the determination of the PTI Board, such decision (i) relates to confidential personnel matters, (ii) is covered by attorney-client privilege, work product doctrine or other recognized legal privilege, (iii) is subject to a legal obligation that Contractor maintain its confidentiality or otherwise would result in the disclosure of confidential information of Contractor’s customers, (iv) would disclose trade secrets, or (v) would present a material risk of negative impact to the security, stability or resiliency of the IANA Naming Function or the Internet. | see above | PTI Board actions are found here: https://pti.icann.org/pti-board-meetings PTI FY21 - FY24 Strategic Plan webinar, Governance is discussed 30 min in https://icann.zoom.us/rec/play/7pUuJe-sqzk3G4DBsASDVvR6W9W9Kfqs0ykd-KFcnU-2U3AFMFr0ZuFBNuVfCHlhqY88Tlio0WeNEuXf?continueMode=true | Kristian Ørmen | PTI Board Actions are listed publically at: https://pti.icann.org/pti-board-meetings Reviewed and Accepted during 21 july 2020 Plenary Meeting | The IFRT finds that PTI Board Actions are listed publicly at: https://pti.icann.org/pti-board-meetings | 18.3.d | |||||||||||||||||||||||||
27 | 26 | Article VI, Section 6.1 (c) | Transparency | Agree not to redact any PTI Board minutes related to decisions concerning the IANA Naming Function, provided that the PTI Board may redact such minutes on the determination that such redacted information (i) relates to confidential personnel matters, (ii) is covered by attorney-client privilege, work product doctrine or other recognized legal privilege, (iii) is subject to a legal obligation that Contractor maintain its confidentiality or otherwise would result in the disclosure of confidential information of Contractor’s customers, (iv) would disclose trade secrets, or (v) would present a material risk of negative impact to the security, stability or resiliency of the IANA Naming Function or the Internet. | see above | https://www.icann.org/resources/board-material/briefing-materials-guidelines-2019-12-20-en | Kristian Ørmen | Policies preventing exclusions in PTI Board Meeting Minutes are documented here: https://www.icann.org/resources/board-material/briefing-materials-guidelines-2019-12-20-en Reviewed and Accepted during 21 july 2020 Plenary Meeting | The IFRT finds that Policies preventing exclusions in PTI Board Meeting Minutes are documented here: https://www.icann.org/resources/board-material/briefing-materials-guidelines-2019-12-20-en. | 18.3.d | |||||||||||||||||||||||||
28 | 27 | Article VI, Section 6.1 (d) | Transparency | Have the General Manager of Contractor and chairperson of the PTI Board sign an annual attestation that Contractor has complied with the requirements of this Section 6.1. | see above | The PTI President signs an annual attestation which is currently not on-line PTI FY21 - FY24 Strategic Plan webinar, Governance is discussed 30 min in https://icann.zoom.us/rec/play/7pUuJe-sqzk3G4DBsASDVvR6W9W9Kfqs0ykd-KFcnU-2U3AFMFr0ZuFBNuVfCHlhqY88Tlio0WeNEuXf?continueMode=true | Kristian Ørmen | Request to ICANN/PTI: Annual Attestations | The PTI President has signed the Annual Attestation every year. The IFRT recommends it be published as well. Reviewed and Accepted during 21 july 2020 Plenary Meeting | The IFRT finds that the PTI President has signed the Annual Attestation every year. The IFRT recommends it be published as well. | 18.3.d | ||||||||||||||||||||||||
29 | 28 | Article VI, Section 6.1 (e) | Transparency | Subject to the terms of this Contract, PTI shall operate to the maximum extent feasible in an open and transparent manner and consistent with procedures designed to ensure fairness, in each case, as such concepts are contemplated by ICANN’s Bylaws. | see above | PTI FY21 - FY24 Strategic Plan webinar https://icann.zoom.us/rec/play/7pUuJe-sqzk3G4DBsASDVvR6W9W9Kfqs0ykd-KFcnU-2U3AFMFr0ZuFBNuVfCHlhqY88Tlio0WeNEuXf?continueMode=true | Kristian Ørmen | The IFRT finds that PTI has operated with an appropriate level of transparency in its decision making. | 18.3.d | ||||||||||||||||||||||||||
30 | 29 | Article VII | AUDITS, MONITORING AND REVIEWS | Notes apply to all of Article VII: Audits, Monitoring & Reviews below. Types of audits/monitoring that contractor agrees to perform and what is published publically | The IFRT finds that PTI has published publically suitable reports and audits on a periodic basis. | ||||||||||||||||||||||||||||||
31 | 30 | Article VII, Section 7.1 (a) | Audits | Contractor shall generate and publish via the IANA Website a monthly audit report identifying each root zone file and root zone “WHOIS” database change request and its status. The relevant policies under which the changes are made shall be noted within each monthly report. Such audit report shall be due to ICANN no later than 15 calendar days following the end of each month. | see above | *not from Plenary, but discussed via email: Question from Kristian: 6.1.A requires to publish the report and yes I agree that they publish the reports. But it refers to 7.1 that states: The relevant policies under which the changes are made shall be noted within each monthly report This is the report as far as I understand:https://www.iana.org/performance/root-audit/202006 Where do I find relevant policies under which the changes are made in the reports? Answer from Kim Davies: The short answer is we do not note the relevant policies in the root audit report on a per request basis. We make an undertaking that they were complied with in the aggregate. This approach was in agreement with NTIA, where the requirement originally came from, and has been continued ever since. The way we conform with this requirement has not been re-evaluated post-transition. Some history may be useful here. This provision is inherited from a requirement that existing in the previous NTIA contract (https://www.ntia.doc.gov/files/ntia/publications/sf_26_pg_1-2-final_award_and_sacs.pdf) "The audit report shall identify each root zone file and root zone “WHOIS” database change request and the relevant policy under which the change was made as well as identify change rejections and the relevant policy under which the change request was rejected." In implementing this requirement, we had a discussion with NTIA and noted the lack of specific policies that govern our work to cite, and the outcome agreed was we would fulfil the requirement by adding boilerplate text that references policy sources at a high-level, which you can see in the very first root audit report in September 2013: All requests were processed according to RFC 1591, ISO 3166-1, and the GAC Principles. (https://www.iana.org/performance/root-audit/201309) In late 2015, NTIA requested a format change to the report to add a section pertaining to pending delegation and transfer activity. In that process the format changed and the revised format NTIA agreed to no longer contained that wording, and instead read: All requests were processed according to relevant policies and procedures. (https://www.iana.org/performance/root-audit/201512) RESPONSE FROM KRISTIAN: Personally i like the reports and from a transparency view I think they fulfill their purpose. But from a contractual compliance view I don’t think they contain the information required in the contract. I agree that this information might not be needed, and especially after reading your mail I agree that it seems unnecessary to include it. This is the first time I take part in a review like this. Is it possible for us to suggest a change to the contract so it would reflect the current practice? Upon the IANA stewardship transition, the format was modified to remove references to NTIA and the specific provision of the IANA contract (C.5.2), and in that process the language was tightened slightly but was fundamentally unchanged: The following requests were implemented during the report period according to the relevant policies and procedures. (https://www.iana.org/performance/root-audit/201610) The reason we ended up with this approach in our collaboration with NTIA is a recognition it is very difficult to directly connect the policy basis for any given change request to a specific policy. RFC 1591 is an informational document written by former IANA staff that has some concepts in it that are retrospectively deemed policy today, but the specific procedural elements in the document are clearly not in practice today. The GAC Principles similarly talks in high-level concepts. There is no formal policy that the ccNSO or GNSO has yet developed yet that specifically applies to the IANA functions. Therefore the aggregate operational tasks we implement are essentially derived from the fundamental tasks that are described in the IANA naming functions contract, the execution of which is largely inherited from past practices, and designed to fall within the parameters of these high-level requirements, but are not directly derived from specific policy requirements. To give an illustration — if a TLD manager requests to change a telephone number in a WHOIS record in the root zone, it is hard to say where we would draw a line to a specific policy that governs that, other than broadly that it is consistent with existing policy and in fulfilment of the requirements of the contract. I hope this is useful context. We are certainly keen to provide maximum transparency in how we perform our work and align our practices correctly — but in a practical sense it is hard to envision a practical way the audit report could be more specific without fundamental associated changes in the sources of our policies. Plenary Call #18: Recommendation that touches contractNew Notice to the IFRT: Any recommendations that will require an amendment to the IANA Naming Functions Requirements has specific requirements from the IFR portion of the Bylaws. 6The IFRT must 1.Consult with the Board2.Consult with PTI3.Consult with CSC4.Conduct a public input session for cc/g operators-Could be a session at ICANN69 -Could be a webinar- need to announce somehow-Cannot be the public comment for the initial report5.Seek public comment on the amendments-This can be combined with the Public Comment for the Initial Report, if we have done the prior consultations first. If the consultations are not done prior to the Initial Report’s Public Comment, then a 2nd Public Comment will need to be held just for the Contract Amendment RecommendationFINAL DECISIONTo avoid a 2nd public comment the IFRT will perform the consultations in this manner:IFRT must1.Consult with the Board-IFRT will send a letter to the Board. The Board could handle via email (vs. waiting for the next Board meeting). Amy to draft.2.Consult with PTI-this is completed due to Kim’s presence3.Consult with CSC-will be handled by James & Amy at the upcoming CSC meeting on 16 Sept 20204.Conduct a public input session for cc/g operators-will hold a webinar- need to announce somehow5.Seek public comment on the amendments-This can be combined with the Public Comment for the Initial Report, if we have done the prior consultations first. If the consultations are not done prior to the Initial Report’s Public Comment, then a 2nd Public Comment will need to be held just for the Contract Amendment RecommendationDECISIONS REACHED1. Removed the Recommendation on .int. See Meeting Notes for details | www.iana.org/performance/root-audit IANA SERVICES OVERVIEW by Kim Davies, ROOT ZONE MANAGEMENT: 40mins https://community.icann.org/display/ifr/Webinar%3A+IANA+Overview+for+IFRT+-+24+January+2020+@17%3A00+UTC | Andreas Dlamini | [AD] Because the report is published publicly and it covers all the required aspects, I don't think there is a need for further evaluation | [AD] The PTI produces the monthly report as required and pubishes it on the website. For April 2020, the report has been published well before the 15 day timeline for submission to ICANN. It is my belief that the report is published on the website after submission to ICANN. Kristian: Recommends that this statement from the section : "The relevant policies under which the changes are made shall be noted within each monthly report" be removed from the contract, as unnecessary and impractical | [AD] PTI carries out the function as required Reviewed and Accepted during 21 july 2020 Plenary Meeting | The IFRT finds that PTI carries out this function as required. | 18.3.d | ||||||||||||||||||||||
32 | 31 | Article VII, Section 7.1 (b) | Audits | Contractor shall annually perform a specialized compliance audit of Contractor’s security provisions relating to the IANA Naming Function against existing best practices and ARTICLE XI. This specialized compliance audit shall be performed by an external, independent auditor. | see above | An external auditor performs a specialized compliance audit of PTI’s security provisions relating to the IANA Naming Function against existing best practices. Description of audit: https://www.iana.org/about/audits IETF review of audit: https://iaoc.ietf.org/contracts.html IANA SERVICES OVERVIEW by Kim Davies, Auditing: 13mins https://community.icann.org/display/ifr/Webinar%3A+IANA+Overview+for+IFRT+-+24+January+2020+@17%3A00+UTC PTI FY21 - FY24 Strategic Plan webinar, Security is discussed 14min in https://icann.zoom.us/rec/play/7pUuJe-sqzk3G4DBsASDVvR6W9W9Kfqs0ykd-KFcnU-2U3AFMFr0ZuFBNuVfCHlhqY88Tlio0WeNEuXf?continueMode=true | Andreas Dlamini | [AD] Interview ICANN Org, CSC and IETF, TLD operators | [AD] The auditor, PwC together with PTI have posted security audit reports that are to do with the Root Zone KSK (service organization control, SOC 3 and not the other aspects of the naming function SOC 2. The SOC 3 reports are good but since I can't access the SOC 2 reports, the audit report produced therefore does not meet the criteria of Section 11. The other thing, it is not clear if the audit will forever be carried out by PwC only. Notes: SOC 2 is comprehensive and successful at meeting requirements and test all ascpects of PTI....some areas cannot be tested, such as on-boarding new staff - without a new employee the audit cannot test if on-boarding is done properly. SOC2 satisfies the requirements of this contract section. Auditors have changed over time and PwC no longer the auditor | Possible question would be: 1) If there is a limit on PwC's contract on the IANA audit functions. 2) If the SOC 2 reports are produced at all and submitted to the relevant bodies. 3) If the TLD operators do receive notifications from the PTI when they are supposed to. | The IFRT finds that PTI has engaged an external auditor on an annual basis. The IFRT has reviewed both the public and confidential reports of the auditor and has found them to be complete and successful, thus meeting the contractual requirement. [consider enhancement of same concept to align more specifically with contract text - statement regarding the conclusions of the audit reports themselves] | 18.3.d | |||||||||||||||||||||||
33 | 32 | Article VII, Section 7.2 (a) | Performance Monitoring | So long as the CSC exists pursuant to ICANN’s Bylaws, Contractor acknowledges and agrees that the CSC is entitled to monitor Contractor’s performance under this Contract (including the SOW) in accordance with ICANN’s Bylaws. | see above | 5. Has PTI provided the CSC with reports that enable the CSC to fulfill it's remit and this section of the contract? ANSWER: Yes. But the CSC has also been discussing areas in the IANA contract that are not being monitored, and discussing if we need new metrics. | https://www.icann.org/csc/reports | Tomslin & James | Has PTI provided and continue to provide the CSC with reports reflecting the SOW? | [Tomslin] NONE | [Tomslin] Monthly reports continue to be provided | N/A | [Tomslin] PTI has provided monthly reports since October 2016 and continues to work with CSC. This is acknowledgement that the CSC is entitled to monitor its performance. Reports are available publically at: https://www.iana.org/performance/csc-reports and the CSC's notification to their customers can be found at: https://www.icann.org/csc/reports Reviewed and Accepted during 21 july 2020 Plenary Meeting | The IFRT finds that PTI has provided monthly reports since October 2016 and continues to work with the CSC. This is acknowledgement that the CSC is entitled to monitor its performance. Reports are available publically at: https://www.iana.org/performance/csc-reports and the CSC's notification to their customers can be found at: https://www.icann.org/csc/reports. | 18.3.d | ||||||||||||||||||||
34 | 33 | Article VII, Section 7.2 (b) | Performance Monitoring | Contractor shall provide reports to the CSC as contemplated by the SOW. | see above | 3. Does the CSC believe it receives reports covering all performance areas within the CSC's remit? ANSWER: Yes, and it is actually too much information with some metrics that are unnecessary for the CSC’s purpose. The CSC is concerned that tracking too many metrics could be a burden to PTI and not be providing any value [note - PTI now has an automated system that tracks and publishes these metrics]. The CSC is learning which metrics to skip in order to pay attention to the most important metrics. [note - Peter stated he preferred more metrics to less] 4. Does ICANN/PTI respond to any report changes that the CSC has ever requested in order to ensure the reports cover the IANA Naming function performance accurately. ANSWER: There has been little need to ask for changes, but on 2 occasions the CSC asked for information to be presented differently and PTI responded immediately. 6. Are the reports provided in a timely manner? ANSWER: Yes, and PTI works very hard to get us the reports before their due date when the CSC needs them early for a face-to-face meeting. The report has never been late. | https://www.iana.org/performance/csc-reports | Tomslin & James | Has PTI provided the CSC with reports reflecting the SOW? | NONE | Reports confirmed | N/A | [Tomslin] PTI has provided a monthly report to the CSC since October 2016. Reports are available publically at: https://www.iana.org/performance/csc-reports and the CSC's notification to their customers can be found at: https://www.icann.org/csc/reports. Above Reviewed and Accepted during 21 july 2020 Plenary Meeting IFRT determined not to include this observation: The CSC believes there is too much information to consume in PTI reports to CSC. The team notes that this concern has not been reported in any CSC reviews. | The IFRT finds that PTI has provided a monthly report to the CSC since October 2016. Reports are available publically at: https://www.iana.org/performance/csc-reports and the CSC's notification to their customers can be found at: https://www.icann.org/csc/reports. | 18.3.d | ||||||||||||||||||||
35 | 34 | Article VII, Section 7.2 (c) | Performance Monitoring | Contractor shall act in good faith to resolve issues identified by the CSC. | see above | Tomslin & James | Outreach question to CSC: whether PTI acted in good faith to resolve issue the CSC identified | [Tomslin] Question sent to CSC for a response | [Tomslin] Outreach question to CSC: In CSC's opinion, has PTI acted in good faith to resolve any performance issues the CSC has identified in the past? | [Tomslin] The IFRT finds that CSC has had excellent support and communication from PTI on any performance matters raised to date. Reviewed and Accepted during 21 july 2020 Plenary Meeting | The IFRT finds that the CSC has had excellent support and communication from PTI on any performance matters raised to date. | 18.3.d | |||||||||||||||||||||||
36 | 35 | Article VII, Section 7.2 (d) | Performance Monitoring | Contractor acknowledges that the CSC shall be empowered to escalate identified areas of concern as set forth in ARTICLE VIII. | see above | 7. Has the CSC needed to in-act the Remedial Action Procedure (called RAPs, this is the escalation process), and if so, how did PTI (& ICANN) react? ANSWER: There has been no cause to utilize the RAPs; no systemic issues. 8. Has the CSC found other issues not covered by the Remedial Action Procedure, that required PTI’s (& ICANN’s) response? If so, what are the details? ANSWER: The SLA changes are the only thing. | Via the Remedial Action Procedures : https://www.icann.org/en/system/files/files/csc-remedial-action-procedures-19feb19-en.pdf | Tomslin & James | Does a CSC escalation process exist. | NONE | YES | N/A | [Tomslin] ICANN, PTI and the CSC developed and approved the Remidial Action Procedures which PTI adopted on February 2019. A copy can be found at: https://www.icann.org/en/system/files/files/csc-remedial-action-procedures-19feb19-en.pdf Reviewed and Accepted during 21 july 2020 Plenary Meeting | The IFRT finds that ICANN, PTI and the CSC developed and approved the Remedial Action Procedures (RAPs) which PTI adopted on February 2019. A copy can be found at: https://www.icann.org/en/system/files/files/csc-remedial-action-procedures-19feb19-en.pdf. | 18.3.d | ||||||||||||||||||||
37 | 36 | Article VII, Section 7.3 all | IANA Naming Function Reviews | (a) Contractor acknowledges that ICANN’s Board of Directors (the “ICANN Board”) may cause a review by an IFRT, relating to the IANA Naming Function, this Contract and Contractor’s performance under this Contract (including the SOW), in accordance with ICANN’s Bylaws (an “IANA Function Review” or “IFR”). (b) Contractor shall cooperate with the conduct of any IFRT, including any site visit conducted by an IFRT that has been previously approved by ICANN in accordance with ICANN’s Bylaws. (c) Contractor agrees that ICANN may unilaterally amend or terminate this Contract (including the SOW) in accordance with an approved IFR Recommendation, an approved Special IFR Recommendation or an approved SCWG Recommendation (as such terms are defined in ICANN’s Bylaws), subject to the limitations set forth in ICANN’s Bylaws. Contractor agrees to abide by and implement any such amendments. | There was no IFR with the US Government before the IANA Stewardship Transition. This obligates PTI to cooperate with this review (IFR). This needed to be in contract becaue the bylaws obligate ICANN to do this review, but no obligation for IANA Functions Operator to cooperate, so we put that requirement here. | IFRT#7[Amy] suggest reviewing this section towards the end of the IFRT | IFR Team | Amy: PTI met this contract requirement through management's cooperation with the IFRT. A PTI liaison was available at all times; PTI set up special interest calls; etc. | The IFRT finds that PTI met this contract requirement through management's cooperation with the IFRT. A PTI liaison was available at all times; PTI management and staff provided support on an as needed basis and has cooperated fully with the actions of the IFRT. | 18.3.b | |||||||||||||||||||||||||
38 | 37 | Article VIII | Escalation Mechanisms | Notes apply to all sections under Article VIII: Escalation Mechanisms listed below: Complaint Resoution proces is spelled out here along with customer naming mediation process. Came from the CWG stewardship which was not in place with US Government contract. Other customer resolution and escalation mechanisms exist (example: CSC's RAPs). Mechanisms to assist before you have to go to extreme of mediation. Putting this in the contract shows ICANNs and PTIs' commitment to resolving customer issues. We do have other mechanisms outside of this contract to maintain customer service levels and resolve issues....such as the CSC. | The IFRT finds that there is an adequate set of mechanisms in place for escalation both internal and via community processes. | ||||||||||||||||||||||||||||||
39 | 38 | Article VIII, Section 8.1 all | Complaint Resolution Process | (a) If Contractor receives a customer service complaint from a customer (a “Complaint”), Contractor will review the Complaint and attempt to resolve it to the reasonable satisfaction of the person or entity who brought the Complaint (the “Complainant”) as soon as reasonably practicable. If the Complaint is not so resolved, the Complainant may escalate the matter in writing to Contractor’s management team, in which case Contractor shall notify the CSC. If the Complaint is still not resolved, the Complainant or the President of Contractor may escalate the matter in writing to ICANN’s Ombudsman. (b) If (i) a Complainant is a customer and (ii) after completing the escalation process provided for in Section 8.1(a), the Complaint is still not resolved, then (A) the CSC may conduct a review to determine whether the Complaint is subject of a persistent performance issue of Contractor or an indication of a systemic problem with Contractor’s performance of the IANA Naming Function pursuant to the terms of this Contract (a “Performance Issue”) and (B) the Complainant may (x) request mediation, which shall be conducted in a manner consistent with the terms and process set forth below in Section 8.1(c) and (y) if the issue is not resolved following such mediation and the Complaint meets the requirements of the Independent Review Process, initiate an Independent Review Process (as defined in the ICANN’s Bylaws). If the CSC determines that a Performance Issue exists, the CSC may seek remediation of the Performance Issue through the IANA Problem Resolution Process described in Section 8.2. (c) Customer Mediation Process. (i) If a Complainant is a customer of Contractor, after completing the escalation process provided for in Section 8.1(a), the customer may initiate mediation by delivering a written notice to the President of Contractor and the Secretary of ICANN. (ii) There shall be a single mediator who shall be selected by the agreement of the customer and ICANN. ICANN shall propose a slate of at least five potential mediators, and the customer shall select a mediator from the slate or request a new slate until a mutually agreed mediator is selected. The customer may recommend potential mediators for inclusion on the slates selected by ICANN. ICANN shall not unreasonably decline to include mediators recommended by the customer on proposed slates and the customer shall not unreasonably withhold consent to the selection of a mediator on slates proposed by ICANN. (iii) The mediator shall be a licensed attorney with general knowledge of contract law and general knowledge of the DNS and ICANN. The mediator may not have any ongoing business relationship with ICANN, Contractor or the customer. The mediator must confirm in writing that he or she is not, directly or indirectly, and will not become during the term of the mediation, an employee, partner, executive officer, director, consultant or advisor of ICANN, Contractor or the customer. (iv) The mediator shall conduct the mediation in accordance with this Section 8.1(c), the laws of California and the rules and procedures of a well-respected international dispute resolution provider. (v) The mediation will be conducted in the English language and will occur in Los Angeles County, California, unless another location is mutually agreed between ICANN, Contractor and the customer. (vi) ICANN, Contractor and the customer shall discuss the dispute in good faith and attempt, with the mediator’s assistance, to reach an amicable resolution of the dispute. (vii) ICANN shall bear all costs of the mediator. (viii) If ICANN, Contractor and the customer have engaged in good faith participation in the mediation but have not resolved the dispute for any reason, ICANN, Contractor and the customer may terminate the mediation at any time by declaring an impasse. 12 (ix) If a resolution to the dispute is reached by ICANN, Contractor and the customer, ICANN, Contractor and the customer shall document such resolution. | see above | IFRT#7: [Fred] anyone used complaint procedure? [Amy] a few excalations that PTI notified the CSC of [Fred]: we could interview these parties to see if they were satisfied [Kim]: PTI could reach out to them and notify them of IFRT work and if open to it, PTI can introduce them to IFRT. [Fred]: we don't need to know subject of complaint; just if the process worked [Kim]: need to go back to team about this | 9. Have known customer complaints been resolved to the CSC's satisfaction? ANSWER: Individual customer complaints and escalations, go through PTI’s customer complaint process, not to the CSC. The CSC would only escalate using the RAPs if a systemic problem was noted within the customer escalations. The CSC is made aware of all customer escalations by PTI, so that the CSC can monitor for determining if there are systemic issues. To date, the CSC has never needed to utilize the RAPs. The CSC frequently gets customers coming directly to them and the CSC redirects them to PTI’s process. 10. What types of complaints has the CSC received? ANSWER: See answer to #9 11. Has the CSC uncovered any systemic problems with the IANA Naming Function services through these complaints? If so, did PTI fix this issue? ANSWER: see answer to #9 | https://www.iana.org/help/complaint-procedure and https://www.iana.org/form/complaint | Tomslin & Fred | Kim will look into past complaints and determine if reaching out to them on feedback regarding complaint process is feasible and useful | [Tomslin] Contact list of parties that have escalated to PTI before [Tomslin] Email requesting the contact list sent to PTI | [Tomslin] In your use of the customer service Complaint Resolution process to escalate unresolved complaints to PTI management/ICANN, would you consider the process effective? | [Tomslin] Where there has been customer complaints, PTI's complaint resolution process has been followed and the CSC duely informed as required by the contract. Reviewed and Accepted during 21 july 2020 Plenary Meeting | The IFRT finds that where there has been customer complaints, PTI's complaint resolution process has been followed and the CSC duly informed as required by the contract. | 18.3.a | ||||||||||||||||||||
40 | 39 | Article VIII, Section 8.2 | IANA Problem Resolution Process | Following the Effective Date, Contractor shall work cooperatively with the CSC to develop “Remedial Action Procedures” for the purpose of addressing Performance Issues. If the CSC determines that a Performance Issue exists, the CSC may seek resolution of the Performance Issue with Contractor, in which case Contractor shall comply with such Remedial Action Procedures if and to the extent the CSC also complies with such procedures. | RAPs were completed by the CSC | see above, 8.1 | https://www.icann.org/en/system/files/files/csc-remedial-action-procedures-19feb19-en.pdf | Tomslin | [Tomslin] Was a Remedial Action Procedure developed? | [Tomslin] NONE | [Tomslin] YES | N/A | [Tomslin] The existing Remedial Action Process adopted by CSC on January 2019 and by PTI on Frebruary 2019, meets the contract's requirements. https://www.icann.org/en/system/files/files/csc-remedial-action-procedures-19feb19-en.pdf However, the CSC believes that there exists a discrepancy of RAP in the ICANN bylaws. The bylaws mention RAP as two different proceedures in sections 18.12(i) and 18.12(ii). The recommendation is that ICANN board considers removing the duplicates. (NOte: james will write recommendation) Reviewed and Accepted during 21 july 2020 Plenary Meeting | The IFRT finds that the existing Remedial Action Procedure (RAP) adopted by CSC on January 2019 and by PTI on February 2019, meets the contract's requirements. https://www.icann.org/en/system/files/files/csc-remedial-action-procedures-19feb19-en.pdf However, the CSC believes that there exists a discrepancy regarding RAP in the ICANN bylaws. The bylaws mention RAP as two different procedures in sections 18.12(i) and 18.12(ii). The recommendation is that ICANN board considers removing the duplicates. (NOte: james will write recommendation) | 18.3.a | ||||||||||||||||||||
41 | 40 | Article VIII, Section 8.3 all | Notice and Mitigation Plan. | (a) Contractor shall promptly inform ICANN of any issue or dispute arising from its performance of the requirements and services contemplated by this Contract prior to the Complaint being escalated pursuant to Section 8.1(a), and shall agree with ICANN on a plan to resolve the Complaint. (b) If, for any reason, Contractor fails to meet any of the requirements of this Contract, Contractor shall (i) conduct an analysis of its operations to determine the root cause of such failure, (ii) develop a mitigation plan to avoid the root cause of such failure from occurring in the future, and (iii) deliver the report to ICANN upon its completion. Contractor shall modify and update any mitigation plan as directed by ICANN. | A mitigation plan: how PTI will figure out how to mitigate issues (handle issues and prevent them from repeating) | IFRT#7:[Fred] how is this done today? [Amy] PTI notifies CSC mail group which I'm on about the escalation. PTI will report out on it by the next CSC meeting. So far they have always resolved before escalation is needed. [Fred] attestation from ICANN that they've been notified of escalations by PTI would suffice? | PTI FY21 - FY24 Strategic Plan webinar, Trust is discussed 7min in https://icann.zoom.us/rec/play/7pUuJe-sqzk3G4DBsASDVvR6W9W9Kfqs0ykd-KFcnU-2U3AFMFr0ZuFBNuVfCHlhqY88Tlio0WeNEuXf?continueMode=true PTI FY21 - FY24 Strategic Plan webinar, Service Delivery is discussed 18min in https://icann.zoom.us/rec/play/7pUuJe-sqzk3G4DBsASDVvR6W9W9Kfqs0ykd-KFcnU-2U3AFMFr0ZuFBNuVfCHlhqY88Tlio0WeNEuXf?continueMode=true | Attestation letter from PTI & ICANN [Tomslin] The attestation will cover the fact that PTI has notified ICANN of all customer escalations but I think Incident reports also have to be examined for the existence any repeat incident. This would determine if there were instances where a mitigation plan was either not provided or it was, but was't followed to prevent repeat of an incident | Request Kim Davies to address escalations: those due to IANA service issues vs. disputes between 2 entities asking IANA to resolve | Amy: There are processes currently in place for individual customer complaints, and a procedure for escalations called the Remedial Action Procedures (RAPs). PTI reports any customer complaints to the CSC to identify any potential systemic issues which PTI would then provide a mitigation plan to address (as part of the RAPs). However, to-date, all customer compliants were resolved without escalation, and the RAPs have never been utilized. | The IFRT finds that there are processes currently in place for individual customer complaints, and a procedure for escalations called the Remedial Action Procedures (RAPs). PTI reports any customer complaints to the CSC to identify any potential systemic issues which PTI would then provide a mitigation plan to address (as part of the RAPs). However, to-date, all customer complaints were resolved without escalation, and the RAPs have never been utilized. | 18.3.a and 18.3.i | |||||||||||||||||||||||
42 | 41 | Article IX | TERM; RENEWAL; TRANSITION AND TERMINATION | Notes apply to all of Article IX: Term, Renewal, Transition & Termination below. Standard to contracts, but written differently for ICANN/PTI. Perpetual renewal; Contract termination, in Bylaws, ICANN would only do so if a recommendation came from a Special IFR (and then PTI has to provide a plan to transition functions to a new operator and needs to ensure operational consistency with no interruptions in service during a transition to a new entity. | No findings required for this section | ||||||||||||||||||||||||||||||
43 | 42 | Article IX, Section 9.1 | Initial Term | The initial term of this Contract will be five years from the Effective Date (the “Initial Term”). | see above | No findings required for this section | 18.3.b | ||||||||||||||||||||||||||||
44 | 43 | Article IX, Section 9.2 all | Renewal; Termination | (a) This Contract will be automatically renewed for successive periods of five years (each, a “Renewal Term”) upon the expiration of the Initial Term and each successive Renewal Term, unless (i) ICANN terminates this Contract pursuant to an SCWG Recommendation arising from an IANA Naming Function Separation Process (as such terms are defined in ICANN’s Bylaws) approved in accordance with ICANN’s Bylaws or (ii) ICANN elects not to renew the Initial Term or any Renewal Term thereafter pursuant to an IFR Recommendation, Special IFR Recommendation, or SCWG Recommendation (as such terms are defined in ICANN’s Bylaws) approved in accordance with ICANN’s Bylaws by providing Contractor with not less than twelve months prior written notice. Any termination or election by ICANN to not renew this Contract under this Section 9.2 must be approved by the ICANN Board to be effective hereunder. (b) Subject to Section 9.2(a), the first Renewal Term shall commence immediately following the end of the Initial Term and each Renewal Term thereafter shall commence immediately following the end of the preceding Renewal Term. Each Renewal Term shall end on the fifth anniversary of the commencement of the Renewal Term. | see above | No findings required for this section | 18.3.b | ||||||||||||||||||||||||||||
45 | 44 | Article IX, Section 9.3 (a), (b), (c) | Transition | (a) Contractor shall develop and maintain, with ICANN input, a plan in place for transitioning the IANA Naming Function to a successor provider to ensure an orderly transition while maintaining continuity and security of operations, including in connection with the nonrenewal of this Contract and/or divestiture or other reorganization of PTI by ICANN as contemplated by ICANN’s Bylaws. The transition plan shall be submitted to ICANN and posted to the IANA Website within 18 months after the Effective Date. The plan shall thereafter be reviewed annually and updated as appropriate. (b) Contractor shall provide support and cooperation to ICANN, and to any successor provider of the IANA Naming Function, in order to effect an orderly, stable, secure and efficient transition of the performance of the IANA Naming Function. (c) Contractor agrees to be engaged in the transition plan and to provide appropriate transition staff and expertise to facilitate a stable and secure transition of the IANA Naming Function to a successor provider. | see above | 12. Has the CSC reviewed PTI's Transition Plan, the plan to transition IANA services to another entity? No, as it is not mentioned in the CSC’s Charter. Partly because the CSC is clearly tasked, in their Charter, with continuing to monitor whichever entity performs the IANA Naming Functions...so if the Transition plan was invoked, the CSC would retain their same roll. However, it is a gap between the CSC Charter and the IANA Contract. Further discussion regarding the wording of “(d) ICANN, in conjunction with the CSC as necessary, shall review the transition plan at least every five years.” Kim Davies: PTI interprets this as that PTI must submit/update a Transition plan every five years, but the CSC’s role is “as necessary”, meaning they are not required to review it but only if necessary. However there is no definition of “necessary” so it may be worthwhile to understand what the community believes to be “necessary”. James: believes the community expects the Transition Plan to be published | CSC Statement dated 2020-07-20 | Tentative: Suzanne/Tomslin | [Tomslin] The transition plan has not yet been published. The CSC has not reviewed the plan since the contract requires them to review it only if ICANN finds it necessary. Reviewed and Accepted during 21 july 2020 Plenary Meeting | The IFRT finds that the transition plan has not yet been published. The CSC has not reviewed the plan since the contract requires them to review it only if ICANN finds it necessary. (Note: May be complete before final report) | 18.3.b | ||||||||||||||||||||||||
46 | 54 | Article XI, Sections 11.4 | Security Plan, Director of Security | Section 11.4 Security Plan. ICANN shall coordinate with Contractor to develop and execute a security plan that meets the requirements of this Contract and this ARTICLE XI. ICANN and Contractor shall document in the security plan the process used to ensure information systems including hardware, software, applications, and general support systems have effective security safeguards, which have been implemented, planned for, and documented. Contractor shall, in coordination with ICANN, perform periodic reviews of the security plan and update the plan as necessary. | see above | PTI Information Security Plan V11, January 2017 is NOT a public document PTI FY21 - FY24 Strategic Plan webinar, Security is discussed 14min in https://icann.zoom.us/rec/play/7pUuJe-sqzk3G4DBsASDVvR6W9W9Kfqs0ykd-KFcnU-2U3AFMFr0ZuFBNuVfCHlhqY88Tlio0WeNEuXf?continueMode=true | Wilhelm & Fred | RW: I don't recall seeing evidence of the "periodic reviews of the security plan" that are mentioned in the Section 11.4 text. (See col M) | RW: I believe that Fred has reviewed the security plan and found it to be satisfactory. I recall that he had a question about what portion of the security plan was ICANN's (as a subcontractor) vs what belonged to IANA. Kim (in Aug 4 mtg): Review of the security plan is something that is provided to the security plan auditors. | The IFRT finds that PTI falls under the ICANN Security Plan, and is satisfied it meets these requirements. The Security Plan is reviewed annually, in that it is an input into PTI's annuall SOC2 report. | 18.3.b | ||||||||||||||||||||||||
47 | 45 | Article IX, Section 9.3 (d) | Transition | (d) ICANN, in conjunction with the CSC as necessary, shall review the transition plan at least every five years. | A Transition plan was completed by PTI | The IFRT finds that in discussions with the CSC, the CSC has determined that this role is on an as-needed basis and not a mandatory clause. The CSC has stated that it remains available to review the transition plan if requested to by ICANN. | 18.3.b | ||||||||||||||||||||||||||||
48 | 46 | Article IX, Section 9.4 | Survival of Terms | Upon the expiration or termination of this Contract under this ARTICLE IX, this Contract shall become wholly void and of no further force and effect, and following such expiration or termination no Party shall have any liability under this Contract to the other Party, except that each Party hereto shall remain liable for any breaches of this Contract that occurred prior to its expiration or termination; provided, however, that the following provisions shall survive the expiration or termination of this Contract: ARTICLE I, ARTICLE III, Section 9.3, ARTICLE XII, ARTICLE XIII, Section 14.1 (but only with respect to obligations accruing prior to the expiration or termination of this Contract), Section 14.2 through Section 14.15, and this Section 9.4. | If any terms need to happen or kept in existence to allow the termination to happen, then ICANN/PTI has obligation to ensure that customers are not impacted | No findings required for this section | 18.3.b | ||||||||||||||||||||||||||||
49 | 47 | Article X | Resources, Fees and Budget | Notes apply to all of Article X: Resources, Fees & Budget below. ICANN takes on obligations of resourcing the IANA Naming Functions appropriately. PTI is budgetted within the ICANN Budget, there is an approved IANA Budget, etc. | The IFRT finds that PTI is provided with sufficient budget for its operations. | ||||||||||||||||||||||||||||||
50 | 48 | Article X, Section 10.1 all | Fees | (a) ICANN shall provide or make available to Contractor the necessary personnel (including seconded employees), material, equipment, services and other resources and facilities to perform Contractor’s obligations under this Contract, including funding in accordance with the Approved IANA Budget. (b) Contractor may not charge or collect fees from third parties related to the performance of the IANA Naming Function without the prior written consent of ICANN. (c) Any fees approved by ICANN and charged by Contractor relating to the IANA Naming Function will be based on the actual costs incurred by Contractor to perform the IANA Naming Function. (d) ICANN acknowledges and agrees that the performance by Contractor of the IANA Naming Function is conditioned upon the full and complete performance of all of the services and obligations required of ICANN under the Services Contract between ICANN and Contractor. | Section 10.1 (b): Long standing clause, even in US Government contract. PTI can't collect it's own fees from customers, or base PTI's level of service on fees that customer pays. (Fees are based on costs, not on generating profit). PTI's ability to perform is dependent on resources ICANN gives to support it. ICANN recognizes that PTI can't provide the required level of service without resources provided by ICANN. | Amy: PTI confirmed that ICANN provided all the necessary support required. | The IFRT finds that PTI has expressed durings its discussions with the IFRT that it is sufficiently supported by ICANN. | 18.3.b | |||||||||||||||||||||||||||
51 | 49 | Article X, Section 10.2 | Budget | Contractor shall comply with the requirements set forth in its Bylaws relating to preparing, submitting and monitoring an annual budget. ICANN will meet annually with the General Manager of Contractor to review the annual budget for the IANA Naming Function, which shall be approved in accordance with Contractor’s Bylaws and ICANN’s Bylaws (“Approved IANA Budget”). | see above | IFRT#7: Support for asking Becky to give IFRT a PTI budget overview | https://pti.icann.org/financial-information-for-public-technical-identifiers-pti | option to request Becky from Finance to give IFRT an overview | Amy: PTI's Operation Plan and Budget goes through a Public Comment before Board approval and is published annually. | The IFRT finds that PTI's Operation Plan and Budget goes through a Public Comment before Board approval and is published annually. | 18.3.d | ||||||||||||||||||||||||
52 | 50 | Article XI | Security Requirements | Notes apply to all of Article XI: Security Requirements below. Security Plan with requirements to ensure the authentication integrity and reliability of IANA Naming functions. | The IFRT finds that | ||||||||||||||||||||||||||||||
53 | 51 | Article XI, Sections 11.1 | Computing Systems, Notification Systems, Data | Section 11.1 Computing Systems. With respect to the performance of the IANA Naming Function, Contractor shall install and operate all computing and communications systems in accordance with best business and security practices. ICANN and Contractor shall implement a secure system for authenticated communications to Contractor’s customers when carrying out the IANA Naming Function pursuant to the terms of this Contract. ICANN and Contractor shall document practices and configuration of all systems. | see above | IFRT#7 [Fred] SOC2 may be reference material for this IANA SERVICES OVERVIEW by Kim Davies, Auditing involves operating systems: 13mins https://community.icann.org/display/ifr/Webinar%3A+IANA+Overview+for+IFRT+-+24+January+2020+@17%3A00+UTC | To view the recording of this meeting: https://community.icann.org/pages/viewpage.action?pageId=138969340 1. Root Zone Management System (RZMS) Kim: Main system is Root Zone Management System: RZMS for tld managers at www.rzm.iana.org, they can submit change requests; interact with pending change requests; etc. also access historical requests. Back-end is a work flow management system, and guides request through operational phases up to validating that the change was done correctly through automation. Automates automation emails; technical checks; interacts with Verisign who publishes root zone data. Administration interface for PTI staff. Internal limitation for PTI users for control & security. Ground up re-write of system is currently going on (system is 17yrs old) and architecture was too limiting. 2 years ago started re-write which is on-going. Will provide basis to then make major changes going forward. Ticketing System: off-shelf Request Tracker. Open source. Original company makes changes for us to customize. Use across all IANA services. On RZM, used for transactions where a lot of customer communication required like ccTLD delegations and transfers required much due diligence. RZMS not suited for this, but is linkage between RZMS and RT (RT has access to RZMS activities.). IP address of root server would be processed though RT. Deployment; 2 data centers (west/east coast US) replicas Run active/active and some active/passive. Run active/passive for RZMS so east is secondary/west primary. Peter: we are not to evaluate system; just check that there is. Some of documentation on system is confidential, so should we note that for next IFR, to determine whether or how this review of systems should go. Contract says it should be documented but not for whose benefit. Kim: NTIA when contract sections added; annual audit audits our systems in much more explicity detail on how we satisfy various controls. NTIA accepted audit as proof. 2. How PTI Audits reviewing PTI’s computing systems Peter: audit- PTI is obliged to this audit in this contract so is contract double requiring same thing? Review team can assume audit ensures this section has been fulfilled. Kim: we cannot dictate that to IFRT but we can state that the audit framework has been in place for time-period of review; team’s choice to trust audit or not as fulfilling purpose of the IFR. Feel that these 3rd party audits are more thorough than ICANN Community Reviews and we have 2 FTE staff on PTI hwo just runs our audit program (16 people total in PTI). So audits are thorough, comprehensive. Fred: isn’t the audit a security one? The contract language is calling for more than security. Kim: it’s a security audit in the broadest meaning of the word. We audit against 3 of the 5 Trust Services Principles and Criteria. The results are dependent on our operational success. The Trust Services Principles and Criteria is an international set of principles and criteria developed and managed jointly by the American Institute of Certified Public Accountants (AICPA) and the Canadian Institute of Chartered Accountants (CICA). The SOC 2 and SOC 3 examination is a rigorous process developed by the AICPA and CICA to provide independent assurance that an organization's systems are reliable. Our SOC certification and reports focus on the following Trust Services principles: • Availability — the system was available for operation and use, as committed or agreed • Processing Integrity — the system processing was complete, accurate, timely, and authorized • Security — the system was protected against unauthorized access. Each principle is supported by well-defined and detailed criteria that encompass a company's infrastructure, software, data, people, and procedures. Peter: audit evaluates systems against ISO standardized criteria. What was behind doing the audit – just this contract, or another obligation? Kim: History of the audit is we started it in 2010 when we began signing the root zone and we audited against SOC3. Started the SOC2 audit for how we process change requests in 2013. (previously called SysTrust). This framework is similar to ISO, but after working with NTIA we determined the SOC framework was best. Draft PTI strategic plan up for Public Comment and identified need to review audit framework over the next 4 years. Peter: I don’t see any audit gaps. Rick: SOC2 is harder to pass then the SOC3. Kim: SOC3 is public attestation about fitness of the system. SOC3 originally pass/fail audit. One “exception” would fail you. Use SOC3 for KSK Operation attestation, so for all 10 years we have done it says “the KSK was operated to 100 % of all controls.” SOC2 is different audience….private assessment, only available to those who have full understanding of system being tested. Detailed assessment with meaningful analysis and so it is confidential. Schematics of network design, details of implementing and deploying systems. This is more useful – not pass/fail, but if you have an exception it provides enough details that you are able to understand how to fix the problem. WE provide this so the people we do business with: Chairs of IETF, IAB, RIRs, ICANN Exectuives. No provision for independent auditor to provide a public opinion. Auditor gives us a private opinion. IETF reviews it and notifies general management if they are satisfied with it….indirect opinion. ICANN wanted a system to provide status updates on requests, NTIA said no, so we put it in the contract that we would have a notification system…..this is the background of why we have these clauses in the contract. We have life-cycle management of all tools (laptops, etc), on-board/off-board staff, staff has limited privilege so they can only access systems/info that pertains to their work. Priveleged access scope limited to staff member’s job. Fred: SOC2 is clean and thorough report. These contract sections are completely covered by SOC2. | Wilhelm & Fred | RW: The completed SOC audits would seem to suffice for ensuring compliance for the technical and physical security measures and requirements of the contract | RW: I believe that Fred has reviewed the (confidential) information security plan | The IFRT finds that the SOC2 audit thoroughly reviews PTI's computing systems, thus satisfactorily meeting the requirement. | 18.3.b | |||||||||||||||||||||||
54 | 52 | Article XI, Sections 11.2 | Computing Systems, Notification Systems, Data | Section 11.2 Notification Systems. Contractor shall implement and thereafter operate and maintain a secure notification system at a minimum, capable of notifying TLD registry operators, of such events as outages, planned maintenance, and new developments. In all cases, Contractor shall notify ICANN of any outages. | see above | see notes in 11.1 | PTI FY21 - FY24 Strategic Plan webinar, Security is discussed 14min in https://icann.zoom.us/rec/play/7pUuJe-sqzk3G4DBsASDVvR6W9W9Kfqs0ykd-KFcnU-2U3AFMFr0ZuFBNuVfCHlhqY88Tlio0WeNEuXf?continueMode=true | Wilhelm & Fred | RW: IFRT should receive sample notification emails that went to both TLD registry operators and ICANN due to outages, planned maintenance, and new developments. | RW: IFRT should receive sample notification emails that went to both TLD registry operators and ICANN due to outages, planned maintenance, and new developments. | The IFRT finds that the SOC2 audit thoroughly reviews PTI's systems, communication and operating processes thus satisfactorily meeting the requirement. Amy: Does Rick still want sample notification emails that went to both TLD registry operators and ICANN due to outages, planned maintenance, and new developments? | 18.3.b | |||||||||||||||||||||||
55 | 53 | Article XI, Sections 11.3 | Computing Systems, Notification Systems, Data | Section 11.3 Data. Contractor shall ensure the authentication, integrity, and reliability of the service data in performing the IANA Naming Function. | see above | see notes in 11.1 | PTI FY21 - FY24 Strategic Plan webinar, Trust is discussed 7min in https://icann.zoom.us/rec/play/7pUuJe-sqzk3G4DBsASDVvR6W9W9Kfqs0ykd-KFcnU-2U3AFMFr0ZuFBNuVfCHlhqY88Tlio0WeNEuXf?continueMode=true | Wilhelm & Fred | RW: IANA has consistently passed its audits, achieved its SLAs, and there have been relatively few customer/stakeholder complaints. Given this, it stands to reason that IANA has ensured the authentication, integriity, and reliability of the service data in its role of handling the Naming Function. | The IFRT finds that PTI has consistently passed its audits, achieved its SLAs, and there have been relatively few customer/stakeholder complaints. Given this, it stands to reason that IANA has ensured the authentication, integriity, and reliability of the service data in its role of handling the Naming Function. | 18.3.b | ||||||||||||||||||||||||
56 | |||||||||||||||||||||||||||||||||||
57 | 55 | Article XI, Sections 11.5 | Security Plan, Director of Security | Section 11.5 Director of Security. Contractor’s Director of Security shall be responsible for ensuring Contractor’s compliance with the technical and physical security measures and requirements of this Contract. | see above | Wilhelm & Fred | RW: The completed SOC audits would seem to suffice for ensuring compliance for the technical and physical security measures and requirements of the contract | RW: IFRT should receive the role description for the Director of Security | RW: I believe that Fred has reviewed the (confidential) information security plan | The IFRT finds that the completed SOC audits suffice for ensuring PTI's compliance for the technical and physical security measures and requirements of the contract. | 18.3.b | ||||||||||||||||||||||||
58 | 56 | Article XII | Confidentiality | Common in contracts. For things that should be non-public and confidential for the purpose of security issues or risk of PTI's ability to maintain integrity of the system, etc. PTI acknowledges it is required to cooperate with dispute resolution procedures, etc. Example for IFRT, review team can ask for these confidential materials. ICANN can determine how the review team should access or protect those materials; how it can be reflected in your report. This section acknowledges exception sto confidentiality requirements. | No findings required for this section | ||||||||||||||||||||||||||||||
59 | 57 | Article XIII | Intellectual Property | Common in contracts: what will happen if new creations are developed by employees and who owns that | No findings required for this section | ||||||||||||||||||||||||||||||
60 | 58 | Article XIV | Miscellaneous | Common in contracts: who pays for what in indemnification. ICANN'S responsibility to indemnify. Notice provisions specified since ICANN can treat performance issues at an arms length. Section says that you can waive one section of the contract (such as it becomes unenforceable because of local laws) without nullifying the entire contract. Establishes viability of this contract. PTI may NOT subcontract IANA Naming Functions out. | No findings required for this section | ||||||||||||||||||||||||||||||
61 | 59 | Annex A | Statement of Work for Management of the DNS Root Zone | Statement of Work (SOW) moves from legal world to technical world . This is the day-to-day responsibilities of PTI. Flagging that we did Amendment No 1 that moved SLAs to outside of the contract to a webpage where a process can amend SLAs without needing a contract amendment. But the rest of this Annex A applies. | No findings required for this section | ||||||||||||||||||||||||||||||
62 | 60 | Annex A, 1 (a) | Root Zone Management | a. The Root Zone Management component of the IANA Naming Function is the administration of certain responsibilities associated with the Internet DNS root zone management. | a. The Root Zone Management component of the IANA Naming Function is the administration of certain responsibilities associated with the Internet DNS root zone management. 3. Authenticate Checks on Customer Requests Kim: RZM – maintain content of root zone and meta data around that to authenticate request and review against policy requirements. Public database that we operate using systems mentioned above and there are multiple phases of processing a request. We accept requests from anyone but in business process we ensure the request is clear and well formed and complete. “well form-ness check” is performed. 2nd phase: perform technical checks: check for errors in what was submitted- is it accurately reflecting data; are they referring to servers we can connect to and reach. We’re not checking servers against practices, we are just trying to catch common areas we can authenticate. This Test was developed in 2007 and we have used it sense, but it might be over-do for review and revisions- PTI staff have some ideas. Other guiding philosophy for technical check is safeguard that this authorized by tld operator. If you want to make change to a name server set (NS records)or ds record, dns, do bit set record that change should have already been effected in zones you control. Ns record update request, then it should have been updated in tld zone first. If you are requesting a ds change, you should have made a match dns key in the tld zone. Typo checks. If party had capability of editing the tld zone then they pass one test towards. Hostile attackers would already have taken over critical system of tld control, so us changing the root zone isn’t making a big difference to the attack. Authorization: anyone can submit request, but has to be authorized. Administrative and technical contact on file for tld need to co-authorize change request. In event if name server change shared by multiple tlds we’ll ask for authorization from other tlds as well. Staff processes request live and do own checks: check any sanctions or regulations pertaining to tlds are satisified and we comply with laws. If it is a material transfer of tld from party to another, we check rules around that. Gtld needs contractual amendment with ICANN, cctld we do due diligence and perform analysis that request is OK to move forward. Public report is drafted and sent to icann board and will make decision about proceeding. Implementation for non-root zone changes happens immediately. NS, Ds, Blue record sent to Verisign via EPP, they re-perform some same technical checks and some checks that check PTI did it correctly. Implement change in 24hrs and then it gets published. PTI check that root zone files did change. Verisign through polling over EPP protocol. Ns set for root servers done over epp – recently development 1 or 2 years ago. Customized version of epp. DNS SEC as configured at high level KSK vs ZSK. PTI operates KKS. Verisign operates ZSK – short lived keys generated – 90 days of ZSK for PTI to sign with KSK ceremony, KSK is trust anchor for DNS, we recognize the unique considerations of risk of disclosure, if tld loses key then they can roll their key and make an emergency change. But PTI doesn’t have that luxury like a tld does, so we need extra precautions. Relationship of IANA and Root Zone Maintainer. PTI needs to work with RZM and we are not allowed to do same work as RZM. RZM needs to be audited too like PTI is? No. RZM contract is different than this contract. No audit requirement in RZM contract. | IFRT#7: [Kim] PTI can provide description of how this is implemented today with pertinent documentation. No single approach. | To view the recording of this meeting: https://community.icann.org/pages/viewpage.action?pageId=138969340 | IANA SERVICES OVERVIEW by Kim Davies, ROOT ZONE MANAGEMENT: 40mins in https://community.icann.org/display/ifr/Webinar%3A+IANA+Overview+for+IFRT+-+24+January+2020+@17%3A00+UTC | Fred & Peter | The IFRT finds that PTI performs its role in the management of the root zone satisfactorily. | 18.3.b | ||||||||||||||||||||||||
63 | 61 | Annex A, 1 (b) | Root Zone Management | b. Contractor shall collaborate with Interested and Affected Parties to develop, maintain, enhance and post performance standards for Root Zone Management. Specifically, Contractor shall perform Root Zone Management in accordance with the service levels set forth in Section 2. | see notes in 1 (a) | https://www.iana.org/domains/root IANA SERVICES OVERVIEW by Kim Davies, ROOT ZONE MANAGEMENT: 40mins in https://community.icann.org/display/ifr/Webinar%3A+IANA+Overview+for+IFRT+-+24+January+2020+@17%3A00+UTC IANA SERVICES OVERVIEW by Kim Davies, Performance Reporting: 27min https://community.icann.org/display/ifr/Webinar%3A+IANA+Overview+for+IFRT+-+24+January+2020+@17%3A00+UTC | Fred & Peter | The IFRT finds that PTI performs its role in the management of the root zone satisfactorily. | 18.3.a | ||||||||||||||||||||||||||
64 | 62 | Annex A, 1 (c) | Root Zone Management | c. Contractor shall also implement DNSSEC in all zones for which ICANN has technical administration authority. | see notes in 1 (a) | Fred & Peter | The IFRT finds that DNSSEC is implemented in the zones where ICANN is the technical administration authority. | 18.3.b | |||||||||||||||||||||||||||
65 | 63 | Annex A, 1 (d) (i) | Root Zone Management | d. Contractor shall facilitate and coordinate the root zone of the domain name system, and maintain 24 hour-a-day/7 days-a-week operational coverage. Contractor shall work collaboratively with the Root Zone Maintainer, in the performance of this function. i. Contractor shall receive and process root zone file change requests for TLDs. These change requests include addition of new or updates to existing TLD name servers (“NS”) and delegation signer (“DS”) resource record (“RR”) information along with associated “glue” (A and AAAA RRs). A change request may also include new TLD entries to the root zone file. Contractor shall process root zone file changes as specified in Section 2 of this Annex A. | see notes in 1 (a) | https://www.iana.org/domains/root/help IANA SERVICES OVERVIEW by Kim Davies, ROOT ZONE MANAGEMENT: 40mins in https://community.icann.org/display/ifr/Webinar%3A+IANA+Overview+for+IFRT+-+24+January+2020+@17%3A00+UTC PTI FY21 - FY24 Strategic Plan webinar, Service Delivery is discussed 18min in https://icann.zoom.us/rec/play/7pUuJe-sqzk3G4DBsASDVvR6W9W9Kfqs0ykd-KFcnU-2U3AFMFr0ZuFBNuVfCHlhqY88Tlio0WeNEuXf?continueMode=true | Fred & Peter | The IFRT finds that PTI performs its role in the management of the root zone satisfactorily. | 18.3.a | ||||||||||||||||||||||||||
66 | 64 | Annex A, 1 (d) (ii) | Root Zone Management | ii. Contractor shall maintain, update, and make publicly accessible a Root Zone registration database with current and verified contact information for all TLD registry operators. The Root Zone registration database, at a minimum, shall consist of the following data fields: domain status and contact points for resolving issues relating to the operation of the domain (comprised of at least organizational name, postal address, email address and telephone number). Contractor shall receive and process root zone registration data change requests for TLDs. | see notes in 1 (a) | https://www.iana.org/domains/root/db IANA SERVICES OVERVIEW by Kim Davies, ROOT ZONE MANAGEMENT: 40mins in https://community.icann.org/display/ifr/Webinar%3A+IANA+Overview+for+IFRT+-+24+January+2020+@17%3A00+UTC | Fred & Peter | The IFRT finds that PTI performs its role in the management of the root zone satisfactorily. | 18.3.a | ||||||||||||||||||||||||||
67 | 65 | Annex A, 1 (d) (iii) | Root Zone Management | iii. Contractor shall apply existing policies in processing requests related to the Delegation, Revocation and Transfer of ccTLDs, including RFC 1591 as interpreted by the FOI and any further clarification of these policies developed by the ccNSO, as appropriate under ICANN’s Bylaws, and approved by the ICANN Board. In addition to these policies, Contractor shall, where applicable, consult the GAC 2005 ccTLD Principles. If an existing policy framework does not cover a specific situation, Contractor will use commercially reasonable efforts to consult with and provide opportunity for input from Significantly Interested Parties and, where necessary, may request the ccNSO to undertake policy development work to address such issues. | To view the recording of this meeting: https://community.icann.org/pages/viewpage.action?pageId=138969340 RZM Policy and RFC1591 RFC1591 – 1994 published. Intended to be a user guide. Now interpreted as policy. FOI is ccNSO’s S Framework of Interpretation and Delegation of ccTLDs (FOIWG): https://ccnso.icann.org/en/workinggroups/foiwg.htm which provides implementation guidance on interpreting RFC1591. Obligation for PTI to do consultation if policy is insufficient in covering situations. PTI did that – like identifying lack of guidance for retiring tlds. Pushing ccNSO to take this on and hope it’s near completion. Peter: draft retirement policy still in public comment period, contract shall apply existing policies ccNSO will not go through all requests in recent years. Re-delegation requests documented on IANA website. ccNSO usually reviews ever incidence of prior happening, and working group may review all instances of cctld transfer and analyze it. | PTI FY21 - FY24 Strategic Plan webinar, Governance is discussed 30 min in https://icann.zoom.us/rec/play/7pUuJe-sqzk3G4DBsASDVvR6W9W9Kfqs0ykd-KFcnU-2U3AFMFr0ZuFBNuVfCHlhqY88Tlio0WeNEuXf?continueMode=true | Fred & Peter | The IFRT finds that PTI performs its role in the management of the root zone satisfactorily. | 18.3.a | ||||||||||||||||||||||||||
68 | 66 | Annex A, 1 (d) (iv) | Root Zone Management | Contractor shall apply existing policy frameworks in processing requests related to retirement of a ccTLD, including RFC 1591 as interpreted by the FOI and any further clarification of these policies developed by the ccNSO, as appropriate under ICANN’s Bylaws, and approved by the ICANN Board. If an existing policy does not cover a specific situation, Contractor will use commercially reasonable efforts to consult with and provide opportunity for input from Significantly Interested Parties and, where necessary, may request the ccNSO to undertake policy development work to address such issues. | see notes in 1 (a) | PTI FY21 - FY24 Strategic Plan webinar, Governance is discussed 30 min in https://icann.zoom.us/rec/play/7pUuJe-sqzk3G4DBsASDVvR6W9W9Kfqs0ykd-KFcnU-2U3AFMFr0ZuFBNuVfCHlhqY88Tlio0WeNEuXf?continueMode=true | Fred & Peter | The IFRT finds that PTI performs its role in the management of the root zone satisfactorily. | 18.3.a | ||||||||||||||||||||||||||
69 | 67 | Annex A, 1 (d) (v) | Root Zone Management | Contractor shall verify that all requests related to the delegation and redelegation of generic TLDs are consistent with the procedures developed by ICANN. | see notes in 1 (a) | PTI FY21 - FY24 Strategic Plan webinar, Service Delivery is discussed 18min in https://icann.zoom.us/rec/play/7pUuJe-sqzk3G4DBsASDVvR6W9W9Kfqs0ykd-KFcnU-2U3AFMFr0ZuFBNuVfCHlhqY88Tlio0WeNEuXf?continueMode=true IANA SERVICES OVERVIEW by Kim Davies, Auditing involves operating systems: 13mins https://community.icann.org/display/ifr/Webinar%3A+IANA+Overview+for+IFRT+-+24+January+2020+@17%3A00+UTC | Fred & Peter | The IFRT finds that PTI performs its role in the management of the root zone satisfactorily | 18.3.a | ||||||||||||||||||||||||||
70 | 68 | Annex A, 1 (d) (vi) | Root Zone Management | Contractor shall maintain an automated root zone management system that, at a minimum, includes (A) a secure (encrypted) system for customer communications; (B) an automated provisioning protocol allowing customers to manage their interactions with the root zone management system; (C) an online database of change requests and subsequent actions whereby each customer can see a record of their historic requests and maintain visibility into the progress of their current requests; (D) a test system, which customers can use to meet the technical requirements for a change request; and (E) an internal interface for secure communications between the Contractor and the Root Zone Maintainer. | see notes in 1 (a) | https://www.iana.org/domains/root PTI FY21 - FY24 Strategic Plan webinar, Service Delivery is discussed 18min in https://icann.zoom.us/rec/play/7pUuJe-sqzk3G4DBsASDVvR6W9W9Kfqs0ykd-KFcnU-2U3AFMFr0ZuFBNuVfCHlhqY88Tlio0WeNEuXf?continueMode=true IANA SERVICES OVERVIEW by Kim Davies, Auditing involves operating systems: 13mins https://community.icann.org/display/ifr/Webinar%3A+IANA+Overview+for+IFRT+-+24+January+2020+@17%3A00+UTC IANA SERVICES OVERVIEW by Kim Davies, ROOT ZONE MANAGEMENT: 40mins in https://community.icann.org/display/ifr/Webinar%3A+IANA+Overview+for+IFRT+-+24+January+2020+@17%3A00+UTC | Fred & Peter | The IFRT finds that PTI operates an RZMS in compliance with this requirement. | 18.3.a | ||||||||||||||||||||||||||
71 | 69 | Annex A, 2 (a) | Service Levels | Contractor shall perform the Services in accordance with the following “Service Levels”. The expectation is that Contractor will normally perform within the threshold. The thresholds will be modified over time as part of periodic reviews of the service level expectation. A subset of the following measures relate to measurement of non-routine changes where it is not applicable to set a specific threshold for performance. It is expected for measurements of non-routine process steps these will only be reported with no applicable service level expectation. | PTI publishes a SLA report referred to as the CSC Report (https://www.iana.org/performance/csc-reports). (PTI's Report: and the CSC's analysis: https://www.icann.org/csc/reports). The CSC meets on a monthly basis to review this report, and determine if there are any recurring issues that need to be addressed. Should such an issue arise, the CSC would trigger the Remedial Action Procedures {RAPs). The CSC and PTI may determine that the SLA metric is not accurately reflecting the purpose of the SLA. The CSC, PTI or ICANN would trigger the Process for Amending the IANA Naming Service Level Agreements. (the RAPs and SLA Change process can be found on: https://www.icann.org/en/csc/other-procedures). Also review the CSC's homepage, from which all of these pdfs can be found: https://www.icann.org/csc IANA SERVICES OVERVIEW by Kim Davies, Performance Reporting: 27min https://community.icann.org/display/ifr/Webinar%3A+IANA+Overview+for+IFRT+-+24+January+2020+@17%3A00+UTC | Review PTI/CSC reports to determine if SLAs are met within expected range. See "PTI-CSC REPORTS" Sheet in THIS spreadsheet for the % of metrics met by PTI from 2016 to tody. There will be an IFRT-CSC meeting to discuss this | NONE | Since 2016, PTI has consistently met between 95.0 to 100% of SLAs. Metric thresholds have been adjusted twice, utilizing the SLA Change Process (See "PTI-CSC REPORTS" Sheet in THIS spreadsheet) | The IFRT finds that PTI operates within the services levels on a monthly basis, as confirmed by the CSC. | 18.3.a | |||||||||||||||||||||||||
72 | 70 | Annex A, 2 (b) | Service Levels | Services Definitions i. Category I (Routine updates impacting Root Zone File). Routine change requests that alter the technical data published in the DNS root zone (e.g. changes to NS records, DS records and glue records). A third party may be engaged to compile, publish and distribute the root zone. ii. Category II (Routine updates not impacting Root Zone File). Routine change requests that do not alter the DNS root zone (e.g., contact data and metadata). These changes do not require changes to the root zone. iii. Category III (Creating or Transferring a gTLD). Requests to create (“delegate”) or transfer (“redelegate” or “assign”) a generic TLD. These changes require additional processing by Contractor to ensure policy and contractual requirements associated with a change of control for the TLD are met. iv. Category IV (Creating or Transferring a ccTLD). Requests to create or transfer a country-code TLD. These changes require additional processing by Contractor to ensure policy requirements are met. This processing includes additional analysis on the change request, production of a report, and review of the report (including verification that all existing registration data has been successfully transferred from the old to new registry operator). v. Category V (Other change requests). Other non-routine change requests. Contractor is required to process change requests that may have special handling requirements, or require additional documentary evidence or clarifications from the customer or third parties, that prevent automating the handling of the request. These requests include, but are not limited to: 1. Customers that require requests to be handled outside the online self-service platform, such as those lodging change requests through the exchange of postal mail; 2. Customers that have placed special handling instructions on file with Contractor, or have otherwise asked for special handling for a request that deviates from the normal process, resulting in the request being executed manually; 3. Unique legal or regulatory encumbrances that must be satisfied that require additional processing; 4. Removing a TLD from service (i.e. retirement or revocation); and 5. Changes that relate to the operation of the root zone itself, including changing the Root Key Signing Key, altering the set of authoritative name servers for the root zone (i.e. the “root servers”), and changes to the “root hints”. | The IFRT finds that PTI operates within the services levels as confirmed by the CSC on a monthly basis. | 18.3.a | |||||||||||||||||||||||||||||
73 | 71 | Annex A, 2 (c through g) | Service Levels | Annex A (= SOW), Section 2, subsections (c) through (g) are “deleted” and replaced with ‘Amendment No.1 to IANA NaminAmendment No. 1 to IANA Naming Function Contract’ as of 07 May 2019 deleted Section 2, subsections (c) through (g) of the Annex A (=SOW) and replaced while also moving the Service Level Agreements (SLAs) to https://pti.icann.org/iana-naming-function-services-service-level-agreementsg Function Contract’ | No findings required for this section | ||||||||||||||||||||||||||||||
74 | 72 | Annex A, 3 | Performance Metric Requirements | No findings required for this section | |||||||||||||||||||||||||||||||
75 | 73 | Annex A, 3 (a) | Program Reviews and Site Visits | i. Contract acknowledges that the CSC is entitled to conduct reviews in accordance with ICANN’s Bylaws and the CSC Charter. ii. Contractor acknowledges that an IFRT is entitled to conduct site visits in accordance with ICANN’s Bylaws. | The IFRT finds that the CSC is satisfied that PTI provides all necessary support to the CSC in order for the CSC to operate in its oversight role. To-date, the CSC has not requested a site visit. | ||||||||||||||||||||||||||||||
76 | 74 | Annex A, 3 (b) | Monthly Performance Progress Report. | Contractor shall prepare and submit reports as mutually agreed between Contractor and the CSC. | 3. Does the CSC believe it receives reports covering all performance areas within the CSC's remit? ANSWER: Yes, and it is actually too much information with some metrics that are unnecessary for the CSC’s purpose. The CSC is concerned that tracking too many metrics could be a burden to PTI and not be providing any value [note - PTI now has an automated system that tracks and publishes these metrics]. The CSC is learning which metrics to skip in order to pay attention to the most important metrics. [note - Peter stated he preferred more metrics to less] 4. Does ICANN/PTI respond to any report changes that the CSC has ever requested in order to ensure the reports cover the IANA Naming function performance accurately. ANSWER: There has been little need to ask for changes, but on 2 occasions the CSC asked for information to be presented differently and PTI responded immediately. 5. Has PTI provided the CSC with reports that enable the CSC to fulfill it's remit and this section of the contract? ANSWER: Yes. But the CSC has also been discussing areas in the IANA contract that are not being monitored, and discussing if we need new metrics. 6. Are the reports provided in a timely manner? ANSWER: Yes, and PTI works very hard to get us the reports before their due date when the CSC needs them early for a face-to-face meeting. The report has never been late. 7. Has the CSC needed to in-act the Remedial Action Procedure (called RAPs, this is the escalation process), and if so, how did PTI (& ICANN) react? ANSWER: There has been no cause to utilize the RAPs; no systemic issues. 8. Has the CSC found other issues not covered by the Remedial Action Procedure, that required PTI’s (& ICANN’s) response? If so, what are the details? ANSWER: The SLA changes are the only thing. | https://www.iana.org/performance/csc-reports, (and indirectly, but not due to a contractual requirement, the CSC reports at https://www.icann.org/en/csc/reports). b refers to same reports as d below, but this specifies the report’s creation | Ask CSC this question: Has PTI provided the CSC with reports as agreed upon between PTI and the CSC? (A summary for the PTI/CSC reports is in this spreadsheet on tab "PTI-CSC REPORTS") | CSC Interview required | The IFRT finds that the monthly report is submitted by PTI to the CSC in time every month. | 18.3.d | |||||||||||||||||||||||||
77 | 75 | Annex A, 3 (c) | Root Zone Management Dashboard. | Root Zone Management Dashboard. Contractor shall work collaboratively with ICANN and Interested and Affected Parties to produce the dashboard to report Service Level Expectations for Root Zone Management, which will be used for real-time reporting of Contractor’s performance. | online dashboard at: https://sle-dashboard.iana.org/ | The IFRT finds that PTI has implemented the SLE dashboard and this dashboard is maintained on an ongoing basis as required by this clause. | 18.3.d | ||||||||||||||||||||||||||||
78 | 76 | Annex A, 3 (d) | Performance Standards Reports | Performance Standards Reports. Contractor shall develop and publish performance standard metric reports for the IANA Naming Function in consultation with the CSC. The performance standards metric reports will be published via a website every month (no later than 15 calendar days following the end of each month). | refers to same reports as b.: https://www.iana.org/performance/csc-reports, but specifies that they must be published. IANA SERVICES OVERVIEW by Kim Davies, Performance Reporting: 27min https://community.icann.org/display/ifr/Webinar%3A+IANA+Overview+for+IFRT+-+24+January+2020+@17%3A00+UTC | The IFRT finds that PTI publishes the performance reports to the satisfaction of the CSC on a monthly basis. | 18.3.d | ||||||||||||||||||||||||||||
79 | 77 | Annex A, 3 (e) | Customer Service Survey | In accordance with ICANN’s Bylaws, Contractor shall collaborate with the CSC and ICANN to maintain and enhance the annual customer service survey consistent with the performance standards for Root Zone Management. The survey shall, at a minimum, include a feedback section for the IANA Naming Function. No later than 60 calendar days after completing a customer service survey, Contractor shall prepare a report (the “CSS Report”), submit the CSS Report to ICANN and publicly post the CSS Report to the IANA Website. | Annual Customer Surveys 2019: https://www.iana.org/reports/2019/customer-survey-20191210.pdf 2018: https://www.iana.org/reports/2018/customer-survey-20181206.pdf 2017: https://www.iana.org/reports/2018/customer-survey-20180118.pdf 2016: https://www.iana.org/reports/2017/customer-survey-20170111.pdf 2015: https://www.iana.org/reports/2015/customer-survey-20151115.pdf 2014: https://www.iana.org/reports/2014/customer-survey-20141217.pdf 2013: https://www.iana.org/reports/2013/customer-survey-20131210.pdf | The IFRT finds that the annual customer survey is performed with input and reporting to the CSC. The CSC is actively involved in the outreach and review of the outcomes of the survey. | 18.3.a | ||||||||||||||||||||||||||||
80 | 78 | Annex A, 3 (f) | Final Report. | Contractor shall prepare and submit a final report on the performance of the IANA Naming Function that documents standard operating procedures, including a description of the techniques, methods, software, and tools employed in the performance of the IANA Naming Function. Contractor shall submit the report to the CSC and ICANN no later than 30 days after the expiration or termination of the Contract. | No findings required for this section | 18.3.b | |||||||||||||||||||||||||||||
81 | 79 | Annex A, 3 (g) | Inspection and acceptance. | ICANN will perform final inspection and acceptance of all deliverables and reports articulated in this Section 3, as set forth in Section 4.10(a) of the Contract. Any deficiencies identified by ICANN shall be corrected by Contractor and resubmitted to ICANN within 10 business days after Contractor’s receipt of notice of such deficiency. | No findings required for this section | 18.3.b | |||||||||||||||||||||||||||||
82 | 80 | Annex A, 4 | BASELINE REQUIREMENTS FOR DNSSEC IN THE AUTHORITATIVE ROOT ZONE | ||||||||||||||||||||||||||||||||
83 | 81 | Annex A, 4 (a) | DNSSEC at the authoritative Root Zone | DNSSEC at the authoritative Root Zone requires cooperation and collaboration between the Contractor and the Root Zone Maintainer. The baseline requirements encompass the responsibilities and requirements for Contractor and these responsibilities and requirements must be implemented in cooperation with similar responsibilities and requirements defined within ICANN’s relationship with the Root Zone Maintainer. | IANA SERVICES OVERVIEW by Kim Davies, ROOT ZONE MANAGEMENT: 40mins https://community.icann.org/display/ifr/Webinar%3A+IANA+Overview+for+IFRT+-+24+January+2020+@17%3A00+UTC PTI FY21 - FY24 Strategic Plan webinar, Security is discussed 14min in https://icann.zoom.us/rec/play/7pUuJe-sqzk3G4DBsASDVvR6W9W9Kfqs0ykd-KFcnU-2U3AFMFr0ZuFBNuVfCHlhqY88Tlio0WeNEuXf?continueMode=true | Wilhelm | RW: Review reference material; Review SOC-3, along with DNSSEC documents at https://www.iana.org/dnssec with most focus on DPS (DNSSEC Practice Statement) | RW: Provided materials along with other content in the public record indicated consistenty cooperation and collaboration between the Contractor and the Root Zone Maintainer. | The IFRT finds that the relationship between PTI and the RMZ is functioning and has received no reports of any deficiencies or improvements required. | 18.3.b | |||||||||||||||||||||||||
84 | 82 | Annex A, 4(b) (i) | General Requirements | The Root Zone system needs an overall security lifecycle, such as that described in ISO 27001, NIST SP 800-53, etc., and any security policy for DNSSEC implementation must be validated against existing standards for security controls. | SOC3: How ICANN’s manage Key signing key. Goal: provide evidence that IANA meets trust services criteria. requirements. Public declaration that we are meeting requirements. SOC2: 2013 started audit to meet IANA contract with US commerce. Audit of processing of IANA related requests. Goal: provide evidence that IANA meets trust requirements. Not for public audience; great level of detail. Goes to chair of IETF, and some other key people like 5 CEO’s of RiRs, and ICANN. ICANN is being audited, and is responsible for this audit. Covers some of IANA systems: PTI identifies critical systems that deliver naming/number/protocal and we audit that – those needed for proper operations and businesses processes. “Registry Assignment and Maintenance System” (RAMS) is internal acronym to summarize systems under audit. We don’t audit everything – such as no auditing of email. Produced by 3rd party independent auditor. Was PWC and now it is RSM (5th largest audit firm internationally). RSM provides a letter regarding their work, responsibilities of reviewing controls and their opinion. All controls were properly implemented. We have had 1 out of 7 reports with a deficiency that IANA fixed. SOC2 Framework has an assertion describing what PTI has done; system under audit. Trust Services Criteria Scope of Report: lists systems, subservice organizations- Coresite (Virginia) and Equinex (El Segundo) are data center providers where ICANN hosts services so we provide their audits to our auditors. SOC2 covers such categories as: Security Commitments, Availability Commitments (like ICANN provides stable environment), Authentication, Demands for how PTI does business often is overseen by ICANN who does HR, Security Training, etc – so if audit has something for PTI to change, PTI would work with ICANN PTI has 1 dedicated employee 100%, and a manager who does 25% for audits CCOP: ensure mission central functions can be performed (subset of IANA Functions not all functions) INTERNAL plan and procedure for maintaining and restoring operations- Key operations only. Annually update. Believe PTI should expand IANA servers to another continent for redundancy. | The SOC 3 audit is described and can be read at: https://www.iana.org/about/audits. The SOC 2 audit covers the same topics but at a more detailed level and is distributed to the oversight bodies: IETF and the five (5) Regional Internet Registries (RiRs) | Wilhelm | RW: Review SOC-3, along with DNSSEC documents at https://www.iana.org/dnssec with most focus on DPS (DNSSEC Practice Statement) | RW: The controls evaluated as part of the SOC-3 provide evidence of an overall security lifecycle for the Root Zone system. Further, the SOC-3 identifies consistency between operational practices and the DNSSEC Practice Statement. DNSSEC Practice Statement is updated consistently and has a structure/model similar to other TLD DNSSEC Practice Statemenets. | The IFRT finds that in reviewing the public and confidential auditors' reports on the security of PTI's systems and processes, PTI operates the RZMS in a secure and stable manner. | 18.3.b | ||||||||||||||||||||||||
85 | 83 | Annex A, 4 (b) (ii) | General Requirements | The remainder of this section highlights security requirements that must be considered in developing any solution. ISO 27002:2005 (formerly ISO 17799:2005) and NIST SP 800-53 are recognized sources for specific controls. Note that reference to SP 800-53 is used as a convenient means of specifying a set of technical security requirements. The systems referenced in this document are assumed to meet all the SP 800-53 technical security controls or equivalent required by a HIGH IMPACT system. | see 4(b)(i) for notes | PTI FY21 - FY24 Strategic Plan webinar, Security is discussed 14min in https://icann.zoom.us/rec/play/7pUuJe-sqzk3G4DBsASDVvR6W9W9Kfqs0ykd-KFcnU-2U3AFMFr0ZuFBNuVfCHlhqY88Tlio0WeNEuXf?continueMode=true IANA SERVICES OVERVIEW by Kim Davies, Auditing involves security: 13mins https://community.icann.org/display/ifr/Webinar%3A+IANA+Overview+for+IFRT+-+24+January+2020+@17%3A00+UTC | Wilhelm | RW: Review SOC-3, along with DNSSEC documents at https://www.iana.org/dnssec with most focus on DPS (DNSSEC Practice Statement) | RW: As per design, the SOC 3 audits against the TSP Section 100, which is a slightly different, but broadly recognized set of security criteria. While the contract section text mentions ISO 27002 and NIST SP 800-53, they are not specifically required as the baseline for any solution. The SOC 3 audit relative to TSP Section 100 is an appropriate set of criteria for IANA. | The IFRT finds that in reviewing the public and confidential auditors' reports on the security of PTI's systems and processes, PTI operates the RZMS in a secure and stable manner. | 18.3.b | ||||||||||||||||||||||||
86 | 84 | Annex A, 4 (b) (iii) | General Requirements | Whenever possible, references to NIST publications are given as a source for further information. These Special Publications (“SP”) are not intended as auditing checklists, but as non-binding guidelines and recommendations to establish a viable IT security policy. Comparable security standards can be substituted where available and appropriate. All of the NIST document references can be found on the NIST Computer Security Research Center webpage (http://www.csrc.nist.gov/). | see 4(b)(i) for notes | Tomslin | [Tomslin] There are no explicit references to NIST publications in both the SOC2 documents and CCOP documents which the team reviewed. Notes: NIST references are made in SOC3 | The IFRT finds that in reviewing the public and confidential auditors' reports on the security of PTI's systems and processes, PTI operates the RZMS in a secure and stable manner. | 18.3.b | ||||||||||||||||||||||||||
87 | 85 | Annex A, 4 c | Security Authorization and Management Policy | Security Authorization and Management Policy i. Contractor shall have its own security policy in place; each security policy must be periodically reviewed and updated, as appropriate. 1. Supplemental guidance on generating a Security Authorization Policy may be found in NIST SP 800-37. ii. The policy shall have a contingency plan component to account for disaster recovery (both man-made and natural disasters). 1. Supplemental guidance on contingency planning may be found in SP 800-34 iii. The policy shall address Incident Response detection, handling and reporting (see 4 below). 1. Supplemental guidance on incident response handling may be found in NIST SP 800- 61. | see 4(b)(i) for notes | PTI FY21 - FY24 Strategic Plan webinar, Security is discussed 14min in https://icann.zoom.us/rec/play/7pUuJe-sqzk3G4DBsASDVvR6W9W9Kfqs0ykd-KFcnU-2U3AFMFr0ZuFBNuVfCHlhqY88Tlio0WeNEuXf?continueMode=true IANA SERVICES OVERVIEW by Kim Davies, Auditing involves security: 13mins https://community.icann.org/display/ifr/Webinar%3A+IANA+Overview+for+IFRT+-+24+January+2020+@17%3A00+UTC | Wilhelm & Tomslin | [Tomslin] Verify that PTI has a Security Policy and verify that: a) the policy is frequently reviewed andupdated b) It includes a DR plan c) It includes incident detection and response plan | [Tomslin] PTI security policy document | [Tomslin] Question for PTI: If and when the security policy is reviewed and updated, how does PTI keep records of these reviews and updates? | [Tomslin] The Security Authorization and Management Policy used by PTI is documented as part of ICANN's overall Security Policy documents which are reviewed annually. PTI does not maintain a separate security policy document. Contingency plans are coverred in PTI's Contingency and Continuity Operation Plan Note: recommendation for PTI to have a separate security plan? Kim: PTI outsources to ICANN through the Services Contract | The IFRT finds that the Security Authorization and Management Policy used by PTI is documented as part of ICANN's overall Security Policy documents which are reviewed annually. PTI does not maintain a separate security policy document. Contingency plans are covered in PTI's Contingency and Continuity Operation Plan | 18.3.b | ||||||||||||||||||||||
88 | 86 | Annex A, 4 (d) | IT Access Control | There shall be an IT access control policy in place and enforced for the key management functions 1. This includes both access to hardware/software components and storage media as well as ability to perform process operations. 2. Supplemental guidance on access control policies may be found in NIST SP 800-12. ii. Users without authentication shall not perform any action in key management. iii. In the absence of a compelling operational requirement, remote access to any cryptographic component in the system (such as hardware security modules) is not permitted. | PTI FY21 - FY24 Strategic Plan webinar, Security is discussed 14min in https://icann.zoom.us/rec/play/7pUuJe-sqzk3G4DBsASDVvR6W9W9Kfqs0ykd-KFcnU-2U3AFMFr0ZuFBNuVfCHlhqY88Tlio0WeNEuXf?continueMode=true IANA SERVICES OVERVIEW by Kim Davies, Auditing involves security: 13mins https://community.icann.org/display/ifr/Webinar%3A+IANA+Overview+for+IFRT+-+24+January+2020+@17%3A00+UTC | Wilhelm & Tomslin | [Tomslin] Verify that PTI has an access Policy and verify that: a) It includes policies on hardware and software access b) it includes policies to keep out unauthenticated users from key management c)it includes a policy to prevent remote access to cryptographic components | [Tomslin] PTI Access policy document | [Tomslin] Access control to hardware/software components and storage media, including appropriate authentication and authorization is documented in ICANN's security policies. These are tested and audited anually as part of SOC2 audit. | The IFRT finds that access control to hardware/software components and storage media, including appropriate authentication and authorization, is documented in ICANN's security policies. These are tested and audited annually as part of the SOC2 audit. | 18.3.b | ||||||||||||||||||||||||
89 | 87 | Annex A, 4 (e) | Security Training | i. All personnel participating in the Root Zone Signing process shall have adequate IT security training. ii. Supplemental guidance on establishing a security awareness training program may be found in NIST SP 800-50. | part of SOC2. Fred will attest that SOC2 covers this according to the contract requirement | Wilhelm | RW: Review roster of personnel involved in Root Zone Signing process. Review materials that provide evidence of IT security training for personnel participating in the Root Zone Signing process (Accomplished via SOC 3; see column M) | RW: -Roster of personnel involved in Root Zone Signing process - Materials that provide evidence of IT security training for personnel participating in the Root Zone Signing process RW: Kim in Aug 4: There is an audit control that there is annual security training for all in-scope personnel; and this is provided as evidence to the auditors | The IFRT finds that the completed SOC audits suffice for ensuring PTI's staff receives adequate security training to meet the requirements of the contract. | 18.3.b | |||||||||||||||||||||||||
90 | 88 | Annex A, 4 (f) | Audit and Accountability Procedures | i. Contractor shall periodically review/update: (1) its formal, documented, audit and accountability policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and (2) the formal, documented procedures to facilitate the implementation of the audit and accountability policy and associated audit and accountability controls. 1. Supplemental guidance on auditing and accountability policies may be found in NIST SP 800-12. 2. Specific auditing events include the following: a. Generation of keys. b. Generation of signatures c. Exporting of public key material d. Receipt and validation of public key material (i.e., from the ZSK holder or from TLDs) e. System configuration changes f. Maintenance and/or system updates g. Incident response handling h. Other events as appropriate ii. Incident handling for physical and exceptional cyber-attacks shall include reporting to ICANN in a timeframe and format as mutually agreed by ICANN and Contractor. iii. The auditing system shall be capable of producing reports on an ad-hoc basis for ICANN or the CSC. iv. A version of the reports provided to ICANN or the CSC must be made publically available. | part of SOC 3 which is public | Wilhelm | RW: Review the SOC 3; review the DPS | RW: Many of the operational detailed contained in Annex A, 4(f) are addressed by the DNSSEC Practice Statement. IANA's adherence to the DPS and other controls is documented by the SOC 3. IANA maintains the frequency of its audits and also maintains the currency of the DPS. Addditionally, the CSC has maintained an active, on-going role in the oversight of IANA. | The IFRT finds that in reviewing the public and confidential auditors' SOC reports on the security of PTIs systems and processes, PTI operates the RZMS in a secure and stable manner. | 18.3.b | |||||||||||||||||||||||||
91 | 89 | Annex A, 4 (g) | Physical Protection Requirements | i. There shall be physical access controls in place to only allow access to hardware components and media to authorized personnel. 1. Supplemental guidance on token based access may be found in NIST SP 800-73. 2. Supplemental guidance on token based access biometric controls may be found in NIST SP 800-76. ii. Physical access shall be monitored, logged, and registered for all users and visitors. iii. All hardware components used to store keying material or generate signatures shall have short-term backup emergency power connections in case of site power outage. (See NIST SP 800-53r3). iv. Appropriate protection measures shall be in place to prevent physical damage to facilities as appropriate. | Wilhelm & Tomslin | [Tomslin] PTI Physical Access policy document | [Tomslin] Policies relating to physical access controls, including monitoring and emergency power backup to hardware components are documented in ICANN's security policies, disaster recovery plan and Contingency and Continuity Operation Plan. All of which are reviewed anually. In addition, these policiese are tested and audited anually as part of SOC2 audit. | The IFRT finds that policies relating to physical access controls, including monitoring and emergency power backup to hardware components, are documented in ICANN's security policies, disaster recovery plan and the Contingency and Continuity Operation Plan (CCOP)- all of which are reviewed anually. In addition, these policies are tested and auditted annually as part of SOC2 audit. | ccop | ||||||||||||||||||||||||||
92 | 90 | Annex A, 4 (h) | All Components | i. All hardware and software components must have an established maintenance and update procedure in place. 1. Supplemental guidance on establishing an upgrading policy for an organization may be found in NIST SP 800-40 ii. All hardware and software components provide a means to detect and protect against unauthorized modifications/updates/patching. | Wilhelm | RW: The SOC 3 covers this, albeit indirectly. Discuss if we want more direct evidence (e.g. an attestation or perhaps evidence of spending in the budget) | The IFRT finds that in reviewing the public and confidential auditors' SOC reports on the security of PTI's systems and processes, PTI operates the RZMS in a secure and stable manner. | ||||||||||||||||||||||||||||
93 | 91 | Annex A, 4 (i) | Interface Basic Functionality | i. Contractor’s interface shall have the ability to accept and process TLD DS records, including: 1. Accept TLD DS RRs a. Being able to retrieve TLD DNSKEY record from the TLD, and perform parameter checking for the TLD keys, including verifying that the DS RR has been correctly generated using the specified hash algorithm. 2. Having procedures for: a. Scheduled roll over for TLD key material; b. Supporting emergency key roll over for TLD key material; and c. Moving TLD from signed to unsigned in the root zone. ii. Ability to submit TLD DS record updates to the Root Zone Maintainer for inclusion into the root zone. iii. Ability to submit RZ keyset to the Root Zone Maintainer for inclusion into the root zone. | IANA SERVICES OVERVIEW by Kim Davies, Auditing involves operating systems: 13mins https://community.icann.org/display/ifr/Webinar%3A+IANA+Overview+for+IFRT+-+24+January+2020+@17%3A00+UTC PTI FY21 - FY24 Strategic Plan webinar, Service Delivery is discussed 18min in https://icann.zoom.us/rec/play/7pUuJe-sqzk3G4DBsASDVvR6W9W9Kfqs0ykd-KFcnU-2U3AFMFr0ZuFBNuVfCHlhqY88Tlio0WeNEuXf?continueMode=true | Wilhelm | RW: I think that Kim did a demo, but I didn't do a checklist to see if we saw all of these. Do we want to have an attestation or a set of screen shots? RW: Discussion by the group during the Aug 4 meeting: general agreement that an attestation from Kim would satisfy this. Additionally Peter observes that updates to DS records are executed consistenty, which should also inform the findings. | RW: Contractor has executed a wide variety of TLD operations, including the ability to handle TLD DS records and performing key rollovers. Without the functionality described in Annex 4, 4(i), IANA would not be able to operate effectively. | The IFRT finds that the updates to DS records are executed consistenty. [for other items inthis section, IFRT has asked Kim to provide an attestation as of teh 04 Aug 2020 IFRT Plenary meeting] | ||||||||||||||||||||||||||
94 | 92 | Amendment 1 | The Parties hereby agree that subsections (c) through (g) of Section 2 of the SOW (Annex A of the Agreement) are deleted and replaced with the following: | No findings are required for this section | |||||||||||||||||||||||||||||||
95 | 93 | Amendment 1: 1 c | Service Levels | Contractor will perform all services relating to Root Zone Management in accordance with the requirements and “Service Levels” specified at https://pti.icann.org/iana-naming-function-services-service-level- agreements#definitions (the “SLAs”), as such services and SLAs may be amended from time to time in accordance with the procedures specified at https://www.icann.org/en/system/files/files/iana-naming-function-sla-amendment- process-28mar19-en.pdf. | PTI FY21 - FY24 Strategic Plan webinar, Service Delivery is discussed 18min in https://icann.zoom.us/rec/play/7pUuJe-sqzk3G4DBsASDVvR6W9W9Kfqs0ykd-KFcnU-2U3AFMFr0ZuFBNuVfCHlhqY88Tlio0WeNEuXf?continueMode=true IANA SERVICES OVERVIEW by Kim Davies, ROOT ZONE MANAGEMENT: 40mins in https://community.icann.org/display/ifr/Webinar%3A+IANA+Overview+for+IFRT+-+24+January+2020+@17%3A00+UTC | The IFRT finds that PTI meets all applied service levels and has supported the CSC in refinement and addition of new SLAs as appropriate. | |||||||||||||||||||||||||||||
96 | 94 | Amendment 1: c (II) through 4 | Service Levels | ii. The fields for the SLAs are as follows: 1. Process. The business process that Contractor is requested to perform. 2. Metric.Theindividualmetricthatwillbemeasuredaspartofthe completion of the business process. 3. Threshold. The specified target for each individual change request. 4. Type. Whether the threshold specified is a minimum target (compliance must not be less than the target) or a maximum target (compliance must not be more than the target). 5. Compliance. The percentage that the target goal in aggregate must be met or exceeded within the specified time period for all requests in the specified category. 6. Period. The time over which compliance is measured. (The period of collecting measurements to meet the Service Level Agreement (SLA)). 1 d. Process Performance. Total Contractor transaction time for emergency changes should be completed within a target of 12 hours until reviewed by the CSC with Contractor. e. These elements reflect activity areas that should be instrumented by Contractor, and reported pursuant to ARTICLE VII of the Contract and Section 3 of this SOW.” 2. The Parties agree that, except as set forth in this Amendment, the current terms and conditions of the Contract will remain unchanged and in full force and effect and, to the extent applicable, such and conditions terms shall apply to this Amendment as if it formed part of the Contract. 3. This Amendment may be executed in one or more counterparts, each of which will be deemed to be an original copy of this Amendment and all of which, when taken together, will be deemed to constitute one and the same agreement. 4. Any signature page delivered pursuant to this Amendment via facsimile, email or other electronic means shall be binding to the same extent as an original signature. Any Party who delivers such a signature page agrees to later deliver an original counterpart to any party that requests it. | The IFRT finds that PTI meets all applied service levels and has supported the CSC in refinement and addition of new SLAs as appropriate. | ||||||||||||||||||||||||||||||
97 | |||||||||||||||||||||||||||||||||||
98 | |||||||||||||||||||||||||||||||||||
99 | |||||||||||||||||||||||||||||||||||
100 |