Dear All, Please find below the action items and notes captured during the IDN Scoping Team call on Thursday, 12 December at 13:00-14:00 UTC. Staff has posted to the wiki space the action items and notes. Please note that these are high-level notes and are not meant as a substitute for the recording and chat room records, which are posted on the wiki at: https://community.icann.org/x/1ZczBw Best Regards, Ariel == Action Item * Staff to find the record of discussion in the UDRP circle regarding how to handle IDN variants by trademark holders. * Staff to extract language from the staff papers related to the update of the EBERO provisions and the same entity requirements that Maxim is concerned about. * Staff to identify the potential impact of delaying the work on the Implementation Guideline 4.0. * Staff to organize two hours of meeting(s) before the scoping team delivers to the Council the outcome of its work. Council will meet on 22 January during the SPS. Schedule first meeting on Thursday, 9 January at 3 UTC. Notes * Need to provide clear language for EBERO. Language regarding requirement of same entity for variants also need to be hashed out. These two issues need to be dealt with in the subsequent working group for IDN topic. * Are we going to be able to identify all the relevant documents that need to be deliberated in the PDP? This needs to be done in the Issue Report, hence a PDP, not an EPDP, is needed. * Same principle would apply at the top level…. provided that RZ-LGR is adopted, variants are not meant for transliteration or translation of a label (top or lower levels). * WG agrees that there are operational issues that need to be dealt with by the contracting parties and staff. A Contracted Party working/negotiation/implementation team that would be focused on IDN Implementation Guidelines 4.0 operational issues (which includes the above and closely related to RA/RRA), to resolve immediate issues and allow for the guidelines 4.0 to be adopted. * A PDP/EPDP that would have a scope including both the IDN Variant TLD define, manage, and coordinate issues as well as the related issue of how the IDN Implementation Guidelines should be revised in the future so that it becomes a GNSO policy. * There are operational issues, regarding IDN table review, intersection between RA/RAA and implementation guidelines. * The issues brought up by Maxim seem to concern with the substance of the implementation guidelines. IDN implementation guidelines have process issues, which will be addressed in the PDP. * Regarding the substance of the IDN implementation guidelines, a small group can work on a 4.1 version with staff and have it completed. 4.0 already includes different stakeholders from the community. * Maxim does not believe an expert group consisting of contracted parties is the right avenue to address the substance of the IDN implementation guidelines. Members in the IPC are needed, for example. * Trademark issues have been discussed in the UDRP circles and addressed many years ago. * Maxim seems to suggest that we need to fix the entire policy process before addressing the operational issues. If that’s the consensus of the group, then we only focus on recommending the PDP/EPDP, and removing recommendation for a small group working on Implementation Guidelines 4.0 operational issues with staff. * The reason for RySG to raise the operational issue is the concern about the impact of variant recommendations on the second level. We may need to revisit the operational issue again if there will be any change to the overall variant recommendation. If we are fine with the substance of the guidelines, then the two phased approach makes sense. If we don’t agree with the substance of the guidelines, then we should only focus on recommending a PDP/EPDP. * The direction seems to be dropping the operational/technical workstream about the Implementation Guidelines 4.0. Nevertheless, there are some troubling issues in the registry agreement that affect 20% of Chinese users. * If variant tables are implemented post-registration, I would imagine that the registry operator will have the ability to grandfather those names. * Dealing with the operational issues in the implementation guidelines is not to change the implementation guidelines, but to feed into the overall PDP/EPDP work on IDNs. It becomes an input to the larger PDP. * We should have the contracted parties work with staff to specifically identify the impact due to the connection between RA/RAA and Implementation Guidelines, and this work will feed into the work of a PDP/EPDP. * IDN G v4.0 allows for registry operator to establish their own policy. We were promised in the past that all IANA IDN tables to be grandfathered, which is not the case now. This is a separate issue, though. Staff is asking RySG to work on a resolution approach. * Recommending an EPDP makes sense, as the existing work seems sufficient. Maxim is against for recommending an EPDP for various reasons. * The issue scoping document does a reasonable job of laying out the facts, context, background information, and supporting documents. * Would an Issue Report cover the operational problems that Maxim is concerning? It depends on the scope of the PDP. If the scope is to investigate those issues, then the Issue Report should cover those matters. * Chartering needs to take place before a PDP starts, and the charter can further clarify what is/is not in scope of the policy development process. * Issue Report won’t preclude other documents to be considered by the policy development process. * One needs to consider the workload in the GNSO and other additional work in the pipeline. If we don’t work on the implementation guidelines and hold this work pending the conclusion of a PDP, then it may be pushed out for potentially a long period of time. * ACTION: Staff to find the record of discussion in the UDRP circle regarding how to handle IDN variants by trademark holders. * ACTION: Staff to extract language from the staff papers related to the update of the EBERO provisions and the same entity requirements that Maxim is concerned about. * ACTION: Staff to identify the potential impact of delaying the work on the Implementation Guideline 4.0. * ACTION: Staff to organize two hours of meeting(s) before the scoping team delivers to the Council the outcome of its work. Council will meet on 22 January during the SPS. Schedule first meeting on Thursday, 9 January at 3 UTC.