[DTM Escalation] Comments before Monday meeting

[Staffan Jonson]

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)

 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).


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?

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?

*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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: CWGPunchList DT-C 0.2.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 22129 bytes
Desc: CWGPunchList DT-C 0.2.docx
URL: <http://mm.icann.org/pipermail/dt6/attachments/20150513/3c7abb67/CWGPunchListDT-C0.2-0001.docx>