[ICANN-CSC] Update on SLA changes

[Elaine Pruis]

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-30sep16
)

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/icann-csc/attachments/20180328/f86c3fd5/attachment.html>