[DTM Escalation] Comments before Monday meeting

[Gomes, Chuck]

Let me once again apologize for my time confusion.

Thanks Staffan for your thoughts.  They are very welcome.  I inserted my responses below.

Chuck

-----Original Message-----
From: dt6-bounces at icann.org [mailto:dt6-bounces at icann.org] On Behalf Of Staffan Jonson
Sent: Wednesday, May 13, 2015 8:58 AM
To: dt6 at icann.org
Subject: [DTM Escalation] Comments before Monday meeting

All
We missed both Avri and Chuck at meeting today, so we decided to postpone meeting till Monday 18/5 rundabout similar time

Proposed agenda for the meeting was:
1. Walk through input (Punchlist) from DT C 2. Walk through of escalation flow charts 3. AOB

In order to speed things up I'm happy to give my input on the Punch list items, since it (hopefully) is uncontroversial

*1. Walk through input (Punchlist) from DT C* Punchlist from DTC:
I'm also engaged in DT-C and is happy with comments submitted by Chuck (From Donna and DT C) 

In punch-list 11-16: CSC design: we committed in DT C not to overregulate the CSC. 
Discussion revolved around giving the CSC the discretion to handle e.g. punch list item no 15:
To agree inbetween CSC and PTI how procedures or remedial actions will be developed post transition (and not before transition)
[Chuck Gomes] I personally am okay with this approach.  I think the test will be whether the full CWG supports it.

 In punch list item 16:
 It is noted that  CSC can escalate complaints to ccNSO and GNSO, which may then decide to take further action "using agreed consultation and escalation  processes."
DT C response:
For ccNSO and GNSO respectively, it is up to their own discretion to formulate internal processes/procedures for escalation. DT C response indicate that such internal processes can be developed post transition (i.e.) not urgent, and that own initiatives for alternative routes to remedies may appear (e.g. direct contact with ICANN board).
[Chuck Gomes] Again, I am personally okay with this approach although I think we may want to recommend that the ccNSO and GNSO develop the needed processes within a specified time period after the transition (e.g., 12 months).  

Sidley punchlist item no 21 relate to what happens if ccNSO/GNSO decide to escalate unresolved issues. To What function/organization would that escalation happen?
DT C answer here is that it is dependent on escalation procedures developed in ccNSO/GNSO, which is post transition). 
This item has been hanging lossely in process for some while now.
My personal view is that the DT C answer is good enough. What about You? 
Are there issues or concern re. item 21 in the punch list, or proposed answer to it?
[Chuck Gomes] 1) Individual registries (at least in the case of gTLDs) may use the IRP process so the GNSO could suggest such an action by impacted registry/registries; 2) the ccNSO or GNSO could recommend mediation or recommend initiating the yet-to-be defined process that could lead to separation.

In punch list item 22: DT C also relates to process that can be developed post transition. 
Any concern for this? I'm happy with the proposed solution. 

As noted in the CSC answer and also noted by Paul Kane in the list, there are demands from several actors in cc community that escalation also need to be specified with consice timeframes for remedials. This specification of service expectations go further than the two dys mentioned by Marika in the list. 

Punch list item 23: Maybe this one need some discussion during next meting Monday?
[Chuck Gomes] Agree.  I wonder if we should propose tasking staff with researching possibilities for mediation options that could be further investigated within a set time period after transition?

*2. Walk through of escalation flow charts* Escalation flow charts sent by Marika are a key improvement for understanding the processes (such charts have already been demanded by cc community members). 


I hope these remarks help for Monday meeting.
 

:)
Staffan

staffan.jonson at iis.se
 +46 73 317 39 67