Page History
The IDN Scoping Team teleconference will take place on Thursday, 10 October 2019 at 13:00 UTC for 60 minutes.
06:00 PDT, 09:00 EDT, 15:00 Paris CEST, 18:00 Karachi PKT, 22:00 Tokyo JST, 00:00 Melbourne AEDT
For other places see: https://tinyurl.com/y54youx5
| Info |
|---|
PROPOSED AGENDA
For Item 3, the collection of relevant documents is here: https://www.icann.org/resources/pages/idn-variant-tld-implementation-2018-07-26-en and document 3 is directly available here: https://www.icann.org/en/system/files/files/idn-variant-tld-recommendations-analysis-25jan19-en.pdf. BACKGROUND DOCUMENTS |
| Info |
|---|
RECORDINGS GNSO transcripts are located on the GNSO Calendar |
| Tip |
|---|
PARTICIPATION |
| Note |
|---|
Notes/ Action Items Dear All, Please find below the action items and notes captured during the IDN Scoping Team call on Thursday, 12 September at 3:00-4: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/sZECBw Best Regards, Ariel == Action Item - Staff to organize a scoping team call on Oct 24 at 3:00 UTC Notes 1. Welcome and roll call 2. What have we tentatively agreed to so far? Review of the summary captured in the Options document (see page 8) Question about whether a PDP is needed - A PDP is needed to adopt the recommendations. - Does the disagreement from the staff paper require additional policy work, or it is something that can be resolved internally? This particular group should not look at the substance of the recommendations. Our main job is to decide whether we have enough stuff to deliberate in a PDP. What we should recommend as the next steps? - If we are proposing a PDP to cover various aspects, it is surely for the PDP to work on this. It is not up to the scoping team to solve all the issues. Question about whether additional research/analysis is needed - Is there additional research and analysis needed? Do we have enough body of information that can be moved into policy work by a group? - If we don’t go down the path of strawman proposal, it would be hard to say what technical impact it would has. - Develop a strawman and see whether standards need to be put into place before a policy is finalized. This work does not seem as straightforward. Because the policy has technical and operational implications, we need to come up with a report, park it there, get the technical issues ironed out before we come back and finalize the policy report. - In the translation and transliteration PDP, there was a strawman of all possibilities as to how T/T may work. All the possible solutions are very detailed and clear, with technical input and pros/cons for each solution. It sounds like an approach that can be applied in IDN variant TLD management policy development. - Going down the path of a PDP, we need extra work done in order to understand the technical and operational impact before we can finalize the policy recommendations. - If we want to defer the technical analysis to an IRT, we can also do that too. If it is not within the knowledge of the group to do the technical analysis, we can leverage other staff like technical staff in GDD, or even consultant. - Park the PDP till some additional research is done to finalize the policy to be recommended. Question about whether an Issue Report is needed - Do we feel the work needs to be done in the preparation of the issue report before the GNSO can take on the subject, or deal with the analysis during the PDP? - This scoping team is trying to determine if the staff reports serve as adequate proxies for an issue report. - The question about whether an issue report is needed helps guide the scoping team’s thought on the options for policy mechanism. - Option A: Leveraging existing PDPs is not the correct approach. - Option B: Create a stand-alone PDP or EPDP. The issue is well represented / understood in the staff document. A likely recommendation is to create an EPDP. - The work already done provides a reasonable set of documents, which can be used to start the PDP and get a sense what the policy might look like. - The scoping team is somewhat undecided about an EPDP or PDP. Maxim feels that some issues need additional work before the policy WG can consider the matter. Some other people feel the set of documents are sufficient and can launch the policy work right away. Take all the staff documents as the starting point of deliberations and add a few more items if needed. - The scoping team is hung up on the EPDP or PDP question. If we go the EPDP route, are we leaving something unaddressed? If we go the PDP route, but acknowledge that there is already existing work that can expedite the first step of the PDP, it wouldn’t be so bad? If we have a full PDP, we just say we have the report from staff and the issue report can be completed by leveraging existing work. - Does the future PDP have the ability to go against the recommendations? The PDP/EPDP would not need be beholden to the recommendations in the staff report. It could come up with different recommendations. Question about what a policy WG would look like - Understand what type of people need to be included in the PDP working group. Stress the importance of expertise in the field. We need to do technical analysis in the course of the PDP itself and need people with the knowledge / expertise. - Instead of restricting membership, we should at least get some members from registrars and some members who understand legal issues. Form a PDP WG with the people of needed expertise. Not a lot of new information needs to be collected. - Support the recommendation to move away from an open WG model, and encourage people with subject matter expertise to join. - If we are talking about trademark issues in this PDP, make sure to invite members from IPC, NCSG, etc. 3. Continued: identifying problems/issues with IDN variant TLD recommendations - Disagree with the report’s assertion that IDN tables could be more easily managed if IDN tables are represented in machine readable format, thus asking to consider the implementation of RFC7940 (LGR in XML format). RFC7940 is a format (like CSV, TXT) to represent something, in this case a label generation ruleset or IDN table. Registries have working implementations that do not necessarily are on XML. RFC7940 could be used to build a new registration system, but it is unpractical to think that registries will retrofit their existing systems with it. - The harmonization of the IDN tables by implementing RFC7940 is going too far. Those not familiar with RFC7940 would have a hard time to implement. We are not going to retrofit how the implementation works. If we are going to represent LGRs in machine readable format, it is one thing. To manage the IDN tables via implementing RFC7940 is another. - The intention for the IDN table recommendation is not to change the internal implementation. The intention is to publish the IDN tables and provide more precise definition. The intention is more output facing, but not for implementation internally. For registries what they publish is what they use internally too, so there is an implication for implementation. - Viability of implementing the “same entity” at the second level. The recommendation touches the surface as to how the “same entity” can be implemented at the second level and the subsequent changes needed to support other operations, like transfer and update operations, availability and RDDS queries. This area needs more research and analysis to find a solution that is widely supported by registries and registrars. - Same entity requirement in the second level is more complicated. Registry contact ID is required. Reality is that some registrars tend to not to reuse the registry contact ID registered by the same registrant. If registries potentially cannot get information from the registrars, they cannot validate who the registrants are. This impacts the transfer. Registries need to know who the losing registrant and winning registrant are, and how many domain names are involved in this transaction. These days, a transfer pertains to a single domain. So when variants are introduced, they are intended to travel as a group. - Policy implementation related to the transfer puts burden on registrars and confuse registrants. - One analogy is the RDAP profile. Registries, Registrars, and ICANN work together to produce a RDAP profile. This can perhaps happen to address the same entity issue. - No fundamental issues with the recommendations but have issues with how they can be implemented. 4. Agreement on what to share with the GNSO Council for the 24 Oct GNSO Council meeting - In terms of update to the Council, it is just what has been discussed so far, including a particular item about inviting other stakeholders to be part of the conversation. - We need to invite those with knowledge in RPMs to the scoping team. The scoping team only has registries/registrars and technical people, and legal people to some degree. If we make a decision on PDP/EPDP, not sure whether it would be accepted by people from IPC and non-commercial group people. Need to create an explanatory letter to the IPC / Non-Commercial people about why we should invite them. Do we need to make another call to specifically invite the IPC, Non-Commercial people? - As for the concerns about representation, that could be captured at a high-level in the options paper shared with Council. And the details would be captured in the Charter. 5. AOB - ACTION ITEM: Staff to organize a scoping team call on Oct 24 at 3:00 UTC |
