[DTM Escalation] DT-M Action Items from CWG Public Comments Review Tool

[Gomes, Chuck]

In follow-up to discussions in today’s CWG calls, another issue we need to discuss has to do with the ALAC comments about escalation to the ccNSO and/or GNSO.  It is item 228 in the comment review tool (colored orange); I pasted it at the end below and added some comments. Please respond to this as well as the other items.  Note that I cc’d Alan so that he can respond to my comments on item 28 to make sure I captured what he said accurately.

Chuck

From: dt6-bounces at icann.org [mailto:dt6-bounces at icann.org] On Behalf Of Gomes, Chuck
Sent: Wednesday, May 27, 2015 2:59 PM
To: DT-M (dt6 at icann.org)
Subject: [DTM Escalation] DT-M Action Items from CWG Public Comments Review Tool

I would like to see if we can address the DT-M Action Items from CWG Public Comments Review Tool on this list without a conference call.  To initiate discussion I have pasted below the rows of the review tool that apply to DT-M and inserted my initial thoughts below each row.  Please respond with any feedback on my thoughts and/or additional suggestions or questions you may have.  Note that whatever we agree to should be sent to DT-C for their consideration.

Chuck

246.


AFRALO

Suggestion for alternative escalation path

We are concerned about the escalation path of the CSC as currently proposed and we suggest that CSC escalates to PTI Board who may ask for a review (from the IFR) or any other action they judge appropriate than the “direct customers” of IANA

The CWG-Stewardship appreciates your feedback and will factor this into its subsequent deliberations.

Action: CWG-Stewardship (DT-M/DT-C) to consider alternative escalation path.


Here are our currently proposed steps in the Problem Resolution Process (Annex J) with possible edits added to accommodate the suggested alternative:




1. CSC reports persistent performance issues to the IANA Functions Operator staff and requests remedial action in a predetermined number of days.

2. CSC confirms completion of remedial action.

3. If CSC determines that the remedial action has been exhausted and has not led to necessary improvements, the CSC is authorized to escalate to the PTI Board.



4. If the performance issues are still not resolved after escalation to the PTI Board, the CSC is authorized to escalate to the ccNSO and/or the GNSO, which might then decide to take further action using agreed consultation and escalation processes.



In my opinion, adding the PTI Board step seems like a reasonable idea.  A similar step could happen in the case of systemic problems.


255.

Centre for Democracy & Technology

Concerns re. step 3 of problem management and lack of detail

We have some concerns that Problem Management step 3 on page 68 - where it is suggested that the CSC escalates to the ccNSO/GNSO - is adding a layer of escalation that may not be necessary. If requests for remedial actions are not being addressed by the IANA functions operator then there is, one must accept, a breakdown in the relationship and trust between the customers and the IANA functions operator. If this is the case, and remedy is not possible, it would seem appropriate for the CSC to call for a SIFR. A trusted relationship between the CSC and the IANA functions operator is absolutely essential to the stability, security and resiliency of the DNS.

Further, the lack of detail relating to how systemic problems will be addressed is concerning. We would suggest that systemic issues/problems should be subject to an SIFR and not just left to the 5 year IFR. Again, the stability, security and reliability of the DNS are paramount, and systemic problems - which are precisely the potential issues this stewardship framework is designed to address - must be dealt with as soon as they are identified.

The CWG-Stewardship appreciates your feedback and will factor this into its subsequent deliberations.

Action: CWG-Stewardship (DT-M) to consider concerns re. step 3 and address lack of detail.




Regarding the suggestion that the CSC could call for a SIFR, it is not clear to me where this would fit in the Problem Resolution Process but, using the edited steps provided below row 246 above, here are a couple possibilities:

·         Insert a step between steps 3 & 4 that calls for a SIFR.

·         Provide the SIFR as an option for the ccNSO and/or GNSO to use in step 4.



Regarding the comments about ‘the lack of detail relating to how systemic problems will be addressed’ here is what Annex J says now:  “The IANA Review Function will include provision to consider whether there are any systemic issues which are impacting IANA naming services, which might then decide to take further action using agreed consultation and escalation processes.”

·         CDT is correct that we do not provide much detail.

·         I think we would agree with them that systemic problems should not be left to the 5-year IFR.

·         If so, we could change the statement about Systemic Problems to something like the following: “The IANA Review Function will include provision to consider whether there are any systemic issues which are impacting IANA naming services, which might then decide to initiate SIFR.”


256.

NCSG

Concerned about inconsistencies and lack of detail


While we agree that the CSC should address issues of concern related to performance directly with the IFO, there may be inconsistencies between the review processes related to the CSC and its responsibilities and the IFR.  According to the consultation document p. 58  “in the event that a material change in the IANA naming services or operations would be beneficial, the CSC reserves the right to call for a community consultation…”  seems to be duplicative of the IFR and in particular the special review that is a component of the IFR.  In addition the proposed CSC consultation process seems at odds with the IFR in that any result of the consultation would be approved by the ccNSO and RySG, a much smaller subset of the community than involved in an IFR. Our preference would be for any such material changes be reviewed as a part of the IFR special review process.


The process for addressing “systemic problems” on p 68 needs to be further elaborated as this is a key part of any escalation process.  While it may be convenient to footnote to “IRP and CCWG Accountability WS 1 mechanisms”, filling this escalation gap with a fully spelled out and credible community based process that is proven and effective will be essential prior to the finalization of the proposal.

The CWG-Stewardship appreciates your feedback and will factor this into its subsequent deliberations.

Action: CWG-Stewardship (DT-M) to review suggested inconsistencies and address lack of detail.




Regarding the “a material change in the IANA naming services or operations” on page 58, it seems to me that this is a DT-C issue so I don’t think it is our place to comment on this.



Regarding the comments about systemic problems on page 68:

·         Should we refer to the SIFR process in Annex F?

·         This would seem to be consistent with the proposed edit regarding systemic reviews above for row 255.



228.

ALAC

Concerns with CSC escalations

The ALAC presumes that all the deliberations and output of the CSC will be completely transparent. Any exclusions must be explicitly documented.

The following comments here also apply to Annex J.

The ALAC does not believe that the ccNSO or the GNSO are the appropriate bodies to which the CSC should escalate problems. There are several reasons for this.
• The ccNSO and GNSO are policy bodies. As such, they should not be in the direct path to address IANA operational issues. That violates one of the prime principles of IANA being operated under the auspices of ICANN.
• The GNSO does not have the processes to investigate or otherwise address operational issues with PTI. The staff assigned to the GNSO are explicitly Policy staff.
• Although the GNSO is a multi-stakeholder body, it has a restricted number of multistakeholders, and assigning escalation to the GNSO would put these stakeholders is a privileged position relative to the rest of those within and outside of ICANN.
• Annex J implies that the only real recourse that the GNSO or the ccNSO would have would be to invoke the community empowerment mechanisms being designed by the CCWG. It makes no sense to first go to the one or two registry SOs instead of going to a community-wide group that actually has the 6 power to take action. This intermediate step will only delay and possible action.

The concept of the Multistakeholder Review team from the original Contract Co model indeed made sense. In this model, it would simply be the empowered group of stakeholder representatives who actually have the power to act on a CSC concern. This group must be provided with staff resources to allow it to function properly.

The CWG-Stewardship appreciates your feedback and will factor this into its subsequent deliberations.

Action: CWG-Stewardship (DT-C/DT-M) to consider feedback on CSC escalation


[Chuck Gomes] If I understood Alan properly, if change the ‘GNSO’ to ‘RySG’, I think that would go a long ways to solving the ALAC concerns.  Here is what I think that would mean in terms of step 4 of the modified Problem Management Escalation Process above with the latest edits in green:

4. If the performance issues are still not resolved after escalation to the PTI Board, the CSC is authorized to escalate to the ccNSO and/or the RySG, which might then decide to take further action using agreed consultation and escalation processes.

Alan: Please suggest further edits to address the ALAC concern.

“This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.”
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/dt6/attachments/20150528/925bfbdd/attachment-0001.html>