Dear all, The notes, recordings and transcripts for the CWG DT-M Meeting 23 March are available here: https://community.icann.org/pages/viewpage.action?pageId=52893656 Action Item * ACTION: In the few ccTLD agreements with ICANN - Check to see if their are provisions about updating root zone and/or interaction with IANA Notes 23 March 2015 Notes: * Good start to DT-M structure to share with larger team; leave Istanbul prepared to complete overal deliverable * IANA escalation email can be used by anyone; channel used very little * Review of Use-Cases; incorrect address could be Compliance enforcement; other use cases; could be redirected to IANA * Nothing formal in place regarding escalation external to IANA, with the exception of the Ombudsman as listed on <http://iana.org/> iana.org * Question: how does Compliance connect to IANA, or vice-versa? * ICANN Contractual Compliance only enforces contracts for which they are a party two, only gTLDs. non-IANA issues for ccTLD registry issues likely addressed at local level (confirmed by Staffan on ccTLDs, especially those that pre-date ICANN) * * ACTION: In the few ccTLD agreements with ICANN - Check to see if their are provisions about updating root zone and/or interaction with IANA * * Question: Should DT-M connect with DT-B? * gTLDs - ICANN Contractual Compliance is most likely route for gTLDs * In case of emergency, can anyone in the community use the Emergency Number? Marika, understanding # is only for direct customers, but if something is flagged as a real emergency, likely not to ignore it. Is there a means of validation of Direct Customers? Call is routed to whomever is on-call. IANA staff likely will know who they are speaking to. * Incident Mgmt (individual Ry Issue) - should the scope of complaintant be expanded? Others with relevant issues? Separation of function similar to CSC/MRT; should be aligned to narrowly defined interests. Update to draft to allow for channel of non-IANA related issues. * DTC recording: emphasized the process that Kurt Pritz suggested. Described more of an internal to IANA then to ICANN escalation path. Should those steps be listed in DT-M draft? The internal escalation approach works up until a need for separation or if IANA were separated from ICANN structurally and not purely internal solution. Some ccTLDs may have issue with interal escalation, leading up to ICANN Board. Separate escalation from gTLDs and ccTLDs; likely not include ICANN Mgmt as part of overall Escalation path. DT-C does not see CSC going beyond operational/technical issues. * Entry points into ICANN 1) IANA email 2)ICANN Customer Svc (phone, email) 3) Contractual Compliance * Escalation to Ombudsman - should have discretion to mediate and ensure right path of escalation, for example CSC or IAP; optional route to Ombudsman for ccTLDs directly to CSC. Basic process can be transferred in case of separation * Step 7 - IAP - reaching limitation to the unknowns in overall proposal. Will an MRT be included? Is IFM been defined outside DT-M? * Yet to know outcome of CSC - DT-C regarding liaisons, etc. * Some issue relating to IANA could be beyond the CSC, such as a new RFP from IETF. * Append Use Cases as appendix to DT-M draft or provide headline statement for issues to assess how they are dealt with that may not traverse the IANA entry. * Problem Mgmt - understanding the types of failures to be resolved at this level. * Preface - DT-N still WIP giving other parts of proposal yet to be determined.
