2019-08-29 IDN Scoping Team Call

Notes/ Action Items

Action Items

None

Notes

1. Welcome, roll call, and staff note on meeting rotation

- Remaining four meetings before ICANN66 will alternate between the 03:00-04:00 UTC and 08:00-09:00 UTC time slots

2. Update about ccNSO efforts

- ccNSO Council Chair plans to send a letter to the ICANN Board next week, requesting to end the ccNSO PDP 2 on the selection of IDN ccTLD strings and inclusion of IDN ccTLDs in the ccNSO. After the Board approves this request and officially ends ccNSO PDP 2, the ccNSO is able to launch its PDP 4, which deals with issues including outlining the differences between the similarity review and IDN variant TLD recommendations.

- The earliest time that the ccNSO is able to launch PDP 4 is during its next Council meeting in September (19 September), if the Board approves its request before that date. The ccNSO aims to launch PDP 4 no later than ICANN66. After the launch of the PDP 4, the ccNSO will form a drafting team to develop charter for its PDP 4 working group.

- Staff are coordinating with ccNSO colleagues to monitor the ccNSO effort, and will advise the GNSO Council on the appropriate timing to send out the call for volunteer message, soliciting GNSO liaison to follow the ccNSO PDP 4.

3. Identify problems/issues related to the IDN guidelines/IDN tables (2nd level)

- There are issues with how the Guidelines get updated, as well as operational and implementation issues with the Guidelines.

- Regarding the “same entity” requirements in the IDN Guidelines, there is no prescription on how it can be achieved. The framework is to have the registry objective ID glued to IDN domain names, which is problematic.

- There is inconsistency between the Registry Agreement and the IDN Guidelines. For example, the guidelines to activate variants in the second level according to the recommendation no.12 of the IDN Guidelines v4 are not consistent with the relevant provisions in Exhibit A of the Registry Agreement. There are provisions pertaining to variant in various parts of the Registry Agreement. How do we reconcile those languages between the two documents?

- In summary, there are three issues related to the IDN Guidelines: 1) change process of the IDN Guidelines (consensus policy related), 2) technical requirements, 3) compliance/legal issues.

- Issue no.3 has been discussed to death during the RA amendment process. ICANN did not change Exhibit A of RA but added Specs 6. The intent is to have the IDN Guidelines rule items that are IDN based. The specific issues were brought by the Chinese community. The main question is whether the CDNC policy can be implemented.

- Not sure how IDN tables intersects with IDN Guidelines.

- RySG raised the issue that a previously approved IDN table for existing TLDs may not be compliant with the standards and technical advice ICANN has received. RySG received a letter from Goran about the process of ICANN org updating its IDN reference tables with the standards and the latest technical advice. The standards have not change since 2008. There is issue with the technical advice (regarding registry service testing processes) that ICANN org gets and incorporates in the tables. This technical advice was not disseminated in advance, so the registries did not know what to expect.

- If the goal is to address security and stability concerns, shouldn’t we update all the IDN tables, not just for the new ones? Usability of the IDN at the 2^nd level should be the main focus.

- All current tables are approved IDN tables, and no table has caused the security and stability problems. Registries are forced to adopt the new tables while the old tables are safe and secure. GDD explains that everything is the same, but when you go through the RST, the previously approved IDN tables get bounced back with additional requirements.

- Need clear requirements for Specs 6 – there are amendments to Specs 6 that refer to another separate work document (e.g., Specification 7 that lays out the requirements for the RPMs which reside in a different document). Need to find a way to reconcile these work documents and not to repeat each other. Pre 2012 Registries do not have to implement the RPM requirements.

- IDN Guidelines are created for everyone, but ccTLDs are not bound to IDN Guidelines. It is creating inconsistency and duplication of language. IDN Guidelines v4 has done a little bit too much, therefore causing the overreach problems perceived by Registries. It causes issues for the gTLD due to the enforcement and compliance mechanism. IDNs are already hard to adopt, so forcing compliance won’t help the push for IDNs. May need the creation of a high-level document to ensure the practice of ccTLDs and gTLDs are consistent. Guidelines can be split for gTLD and ccTLD portions. The gTLD portion can focus on creating more consistency that we are seeking. ccTLDs and gTLDs all have the freedom at 2nd level to do as they find best. 


- Regarding the technical and compliance disconnect in the IDN Guidelines, those issues can be lumped together to get clarification from ICANN org. Regarding the change process of the IDN Guidelines, the entire process has to be reviewed. A working group may need to be created.

- Work in two streams. One stream is to look at the entire change process of the IDN Guidelines. Another stream is to review the backend registry service testing process and the IDN reference tables. There seems to be urgency in clarifying the second work stream items with ICANN. The second stream seems like an effort in the registry side rather than the whole GNSO. It can be a group in the RySG to work it out with ICANN? RST is an internal process of ICANN and up to ICANN how to deal with issues related to it.

- If there are perceived errors regarding how ICANN is implementing the IDN tables and technical requirements in the IDN Guidelines (e.g., widespread feeling that Exhibit A and Specs 6 are somewhat inconsistent and registries don’t know which rules follow), maybe the scoping team can recommend that RySG continues the discussions with ICANN? The GNSO side can focus on the overall change process, i.e., the creation/update of the IDN Guidelines.

- The technical and compliance/legal issues are not just registry issues; they also impact the registrars. The less confusing and the simpler the implementation, the better for the clients of registrars. The “same entity” requirement is extremely relevant to registrars.

- The fundamental question is how we safely use the rules designed for the Root Zone to apply at the second and third level.

- A PDP WG can look at the change process of the IDN Guidelines. To give legitimacy/credibility to the IDN Guidelines is a broader structural question. The GNSO needs to think it through going forward.

- An expert group can review the technical and compliance issues in the IDN Guidelines, which have urgency and need more immediate fixing. The idea of an expert group may work, as IDN is a niche topic. We also should build in opportunity for community input, so the public can review and comment on the outcome of the expert group. We need to ensure that representatives of Ry and Rr to be there (not just individuals) for an expert group to prevent issues we see now with IDN Guidelines v4.

4. Time permitting, start identifying problems/issues with IDN variant TLD recommendations

5. AOB