Dear all, Following are notes and proposed text that Bart put together, and I've reviewed, to provide some context and background on the need to change the language in the charter with respect to amending Service Levels; The starting point is in the current charter in the Review section: “The CSC or the IANA Functions Operator can request a review or change to service level targets. Any proposed changes to service level targets as a result of the review must be agreed to by the ccNSO and GNSO.” Note 1. This section in the current charter is under the heading of Reviews, which may not be the most adequate location in the text. Changes result from monitoring the performance of PTI, and needs from the community ( for example adding SLAs for the IDN tables). Note 2. The section in the charter referenced above is first and foremost related to the service levels as defined in the IANA Naming Function Contract. There may be potential overlap with the section under the Scope of Responsibilities Donna mentioned in her email yesterday. However the CSC used the language in the Review section as a starting point for discussing and suggesting changes to the Service Levels As the Service Level targets are defined in the* IANA Naming Function Contract,* amending the service levels at first reading implies a change of the contract, which could be very heavy handed for most of the changes needed ( see Elaine’s email). Here is the relevant section in the IANA Naming Functions Contract: Section 2.c of Annex A of the Naming Function Agreement, where the SLAs are housed, states: (italics EP) “Either Party (BB Comment: ICANN or PTI) may initiate a change to the *services* performed by Contractor hereunder by delivering to the other a change request, in a form mutually acceptable to the Parties. Thereafter, the Parties will discuss the requested change in good faith and upon the Parties’ *mutual written agreement* that a change to the services performed by Contractor hereunder should be made, such change shall be evidenced in writing and* deemed to be incorporated into this Contract, without any need to amend the terms of this Contract*.” (See: https://www.icann.org/iana_pti_docs/151-iana-naming-function-contract-v-30se... ) Now quoting Sam Eisner: “With that, we see the work here is essentially to develop a subprocess for the CSC, ICANN and PTI to demonstrate that a proposed SLA change is supported by the customers and PTI, and that ICANN and PTI can then agree to modify the SLAs. The full contract modification process is not required in this instance. Some highlights for that subprocess could include (including areas already considered by the CSC to be part of it): - CSC and PTI agree that there is a need for a modification to the SLA (can be reflected in minutes, etc.) - CSC helps consult among/socialize with naming functions customers (Note: this is reflected as a possible public comment period in the process, but ICANN org would not require a comment period for this type of operational change; the consultation process could be designed in another way to reach the appropriate/impacted customers). - Once agreement is reached on the appropriate SLA, identify the proper threshold for documenting the customer support of change. (Note: because this is not a full contract amendment, the CSC could consider if the threshold counts based on the ccSNO and GNSO Council are still appropriate or if it should be tailored more to the customers) - PTI and ICANN Board approval would typically not be required for a change to the SLA, unless it imposed material financial impact to implement, or possibly if modifications to other contracts were needed to accommodate the SLA modification.” With the highlights Sam mentioned in mind, a CSC sub-group started to develop a set of procedures for the different types of changes, the Variable SLA Change Procedures, which were shared with the CSC RT and illustrated by Elaine. As each of the procedures headings states, the starting point is a change to the documented Service Levels. In terms of the CSC, they developed change processes that adequately address the need to remain transparent in all its dealings with PTI-IANA, while not exhausting the respective communities with the necessity to examine and affirmatively acknowledge trivial SLA changes. As the CSC members act as representatives of and remain accountable to their communities they feel that working with PTI-IANA to introduce SLA changes should be a core function of that representation. (EP Note: the ccNSO and RYSG can at anytime recall their appointees; if there is concern that a member is acting out of the interest of the direct customers, they can be replaced). The CSC also expressed that an addition / clarification is required to the current CSC charter. The required change should be made in the “Scope of Responsibilities” section. To avoid any confusion or conflation with responsibilities related to changes to the IFO services we recommend that this new responsibility appear amongst the earlier paragraphs of that section (and hence *replaces* the current language in the Review section) and include in the Scope of Responsibilities an additional subsection directly following the section on monitoring the performance of the IFO. Proposed language to include in the CSC Charter as part of the review team work: *The CSC will develop appropriate processes for engagement with registry operators and the community consultation by which Service Level changes can occur. These processes are commensurate with the nature of the Service Level change being proposed. Informing the registry operators shall always be required. Where the proposed changes are minor, for example a minor change to a target/threshold, a full community consultation would not be required. The processes for amendments of the service level may be updated from time to time, and will only become effective after publication of the process on the CSC webpage, and after informing the ccNSO Council and RySG, the direct customers.* Please let me know if you have any questions. Elaine