[Gnso-epdp-idn-team] Notes and action items - IDNs EPDP Meeting #68 - 02 February 2023
Steve Chan
steve.chan at icann.org
Thu Feb 2 22:54:55 UTC 2023
Dear all,
Please find below the notes and action items from today’s meeting on Thursday, 02 February 2023 at 13:00 UTC
Kind regards,
Ariel, Emily, and Steve (and for this week, a huge note of thanks to Marika for capturing notes!)
Notes and Action Items - IDNs EPDP Call – 02 February 2023
Action Items
Action item #1: ICANN org to share scenarios in which a primary label may become undelegated so that this can be included in the rationale.
Action item #2: Staff support team to circulate definition of critical function (see section six in in Specification 10 here: https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html#specification10). The Critical Functions include: DNS Service; DNSSEC proper resolution; EPP; RDDS; Data Escrow. [COMPLETE]
Notes
Notes – IDN EPDP – 02 February 2023
Roll Call and SOI Updates / Welcome and Chair Updates
* Reminder, staff sent around text for review two weeks ago with a deadline of today (Thursday 2 Feb). If additional time is needed, please indicate this as soon as possible so that there is an indication of when input is expected to be received.
* No meeting next week due to ICANN org all hands meeting.
* A webinar has been scheduled with the GAC on 15 February at 11.00 UTC. This will allow the group to provide an update on the work and progress to date. Further info will be circulated closer to the date. All are welcome to join.
Continued review of ICANN org input
* Take stock of where we are at this point.
* Commenced with non-substantive input that can be applied with no issues (slide 4 – 5) – those updates are in the progress of being made. Everyone will have a change to review these.
* Input for A5 – Rec 1.5 (slide 6) – Best practices may not be ready from a practical perspective before round launches. May only be known after the next round. Were envisioned to help applicants to better prepare. There is also a recommendation in relation to development of criteria – purpose is to sure that applicants are capable to operate the TLD and variants. Observation from the staff side: this element to demonstrate need and capability for variants should go to the same purpose of best practice guideline. The intent of this recommendation may be covered elsewhere, so maybe this recommendation is not as useful at this time. No agreement on how to proceed during the last call, although there was agreement to take this to the list, no discussion to date.
* Leadership suggestion: consider recasting this recommendation. Rather than best practice guidelines, consider recommending that the IRT develops a framework for best practices for the operation of IDN gTLDs and variant labels for registries and registrars.
Team input:
* Best practice should be established by registrars and/or registries – others do not participate in the operation of gTLDs. It is a top down manner of operation.
* Original recommendation foresaw relevant stakeholders participating in development of guidelines (“such as registries, registrars, and registrants who have experience or interest in IDNs in the scripts with allocatable variant labels”).
* Input for A9 – Rec 1.12 (Slide 7) – Agreement on the last call that label states need to be tracked by ICANN and ideally this list is made available for all to see. Rationale may need to be provided for why this would be public as resources would be involved for doing so.
* Input for A10 – Rec 1.13 (Slide 8) – Question is about states and transitions that labels would go through in their lifecycle. What happens if primary label gets revoked, would ICANN org still need to track the IDN variant states? A better word for revoked would be ‘un-delegated’. There is a presumption that the Registry operator would not be able to continue operating the TLD if the primary label is undelegated, would it still be necessary to continue tracking the labels and transitions of the variants in this scenario?
Team input:
* If primary label is not used, it should return to the withheld-same-entity. The set of variants is still the set of variants.
* If the primary is revoked, should the whole set be revoked. This should open a broader discussion as this is almost like a redelegation. Need to think about what would trigger such a situation, for example, update to the RZ-LGR? This would be very different from registry trying to change the primary string. May need to run through some scenarios to better understand.
* Question arises, can you apply for a set, where you never intended to use the primary label?
* Let’s take the question out of the current context and think about the sanctity of the set. In the case of a breach of contract, it would seem that it would disqualify the variants as well. It is a single contract that happens to cover various strings. If there is a breach of contract for one string, doesn’t that automatically affect the others?
* Is it decided yet that it would be one contract? Could also consider multiple contracts.
* Need to distinguish why the primary label is revoked – if it is a contractual issue, then it affects all variants and all should be revoked, but if on the other hand the registry decides that they don’t want the primary label, there should be an opportunity to modify the contract that one of the variants would become the primary label. This could result in changes to other variants if the relationship changes.
* There would be a period of time for the registry to delegate all the strings in the contract. Have not included option of switching out the primary label. Order in which labels are delegated does not matter, but all need to be delegated in a certain period of time. Not sure if we should go down the path of allowing a registry operator to switch out their primary label or any label once they are contracted. Not sure if that is within scope for this group – may be a conversation for registry and ICANN legal.
* Primary label affects allocatable and blocked variants so it may require a recalculation of string similarity and also other parts of the process?
* Logically they are still a set, just because the primary label is revoked that doesn’t change the set. If primary goes out, all should be taken out.
* See slide 8 and 7 – possible to move from delegated to allocated which implies un-delegation. Question is when can that be invoked for primary labels as well as variants. If it cannot be invoked, then #7 may need to be excluded.
* Group seems to agree that it is an all or nothing – if you break the set, you break the sanctity of it.
* Now about the circumstances in which cases it can go from delegated to undelegated. There seem to be two options: 1) Breach of contract, 2) registry operator voluntarily decides no longer to operate the string. If the primary is undelegated, it follows that the variants are undelegated as well.
* There are technical and policy considerations – technically there is not necessarily an issue if a primary label is undelegated, but the policy consideration is what matters here. Need to protect the integrity of the set. Need to be clear about the scenarios, and need to be clear to applicants at the outset.
* If the un-delegation results from action caused by RO then the full set should go out with the primary; if un-delegation is not due to an action caused by the RO, then grandfathering might apply.
* Grandfathering would only apply where there is a change to the RZ-LGR (see A10).
* Is it possible for a registry to request withdrawal of a variant label (only one, not others). If that is possible, is it also possible to request withdrawal of a primary label.
* Variants are not determined by the registry operator, but the RZ-LGR.
* How strongly do we hold the sanctity of the set? Do we allow a variant to be withdrawn if the primary label is still in place? That should be allowed and the variant becomes un-delegated. However, if the primary label is un-delegated, it does affect the set, as the set is determined by the primary label. Need to look at the cause of the un-delegation. If it is a breach of contract, shouldn’t be allowed to keep the variants. But if it is due to something that is not caused by the Registry operator, for example, country language changes result in primary label no longer being valid, or changes to RZ-LGR, there should be exceptions.
* Proposal: for simplicity, allocatable variant labels can be subject to delegation, un delegation provided registry operator justifies and have a transitional plan for existing registration, etc. The primary label is not subject to voluntary un-delegation.
* If the primary goes, the set goes, so the variant label status would no longer need to be tracked either.
* Consider asking how many Registry Operators would apply for IDNs variants sets if it is known that the loss of primary destroys the whole set and all TLDs from it.
* May not be necessary to ask this as loss of a primary label is likely an edge case.
* Would need to keep data for a period of time to be able to track after withdrawal.
Action item #1: ICANN org to share scenarios in which a primary label may become undelegated so that this can be included in the rationale.
* Input for B1 – Rec 2.1 (slide 11) – general concern not specifically about the text in the recommendation but about if an existing registry is granted a variant TLD it would be on an older existing version of the Registry agreement. There is currently no process for moving from on older version to a newer version of the Registry Agreement. May need to provide for a process to be able to do so.
Team input:
* Consider having unified registry agreements but having variety may not be desirable.
* Not considered the option that a Ry may already have an agreement and if it would apply for variants it would be under a new agreement. Need to consider Registry agreement. May be difficult to meld two. Should this be pushed off to the IRT to see how to make this happen, or is this something for the group to address?
* Needs to be clear path for how to deal with this, including specification 14. Having various agreements will be confusing and may cause enforcement issues.
* No change needed to this recommendation. Group to review recommendations in general and rationale to see if there is a way to have the IRT consider the best path forward for this scenario. Note, same would apply for SubPro.
* Input for B2 – Rec 2.2 & Rec 2.3 (slide 12) – originally labelled as non-substantive, but as it is not only about a tweak it would be substitution of language to provide a more precise assessment of what is being recommended.
Team input:
* No concerns, but review if suggestion is consistent with definition of critical function (see https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html#specification10).
Action item #2: Staff support team to circulate definition of critical function.
* Input for D1b – Rec 2.6 – suggestion to separate recommendation into two parts, one for need and one for capability, as well as guidance on criteria that can be used to assess need and capability. If the expertise does not reside within this group to determine criteria, it could also be recommended that an external party develops these criteria for the application process.
Team input:
* No concerns about splitting recommendation into two.
* Not sure what research would be helpful in this regard.
* Is related to evaluation of overall application and technical capability, so may need to be brought into the implementation part as it is interrelated with SubPro on the overall evaluation. May make more sense to link it to that implementation work?
* If this group would not develop the criteria itself, and would ask for research to be done in the future, it would not come back to this group but if adopted would inform implementation and development of application criteria.
* Concerned that this could turn into a substantive effort where it doesn’t need to be. Shouldn’t it be similar to what a ‘normal’ gTLD operator needs to demonstrate? How would it differ from an application for an IDN and/or variants?
* Even if that is the case, may still be necessary to confirm this through research. This shouldn’t be a huge effort. It should be studied alongside the capabilities for any TLD operator.
* Suggestion: demonstrate operational capability to perform the critical functions with respect to second level registration in the Variant TLD set. Stay within what we can measure, but the specific details of what can be measured in terms of variants may need to be deferred to implementation or additional research.
* Consider qualifying the research, if the group decides to go down this path.
* Group to break recommendation in two and expand on implementation guidance 2.7.
* Need question is reasonably subjective. Will be difficult to have set of criteria against which to measure. Primary need would be related to a language community. In 2012 round there was a question about purpose, but it was an unscored question. Maybe that is another way of dealing with it – having it as an unscored question?
* Have not considered yet who would do the evaluation.
* The evaluation piece shouldn’t stray too far from what was in the RZ-LGR. That may be something evaluations could point to. If there is a big deviation, evaluators could ask why this deviation exists.
* Group to further consider the scoring / non-scoring option and see if there is a way to point out what is really important in this recommendation.
* Input for B5-Rec 2.8 (side 14) – in principle non substantive, but given the changes to the text, wanted to check with the group. Org is suggesting to be more precise in what the restrictions may be, and list out in implementation guidance what the specific restrictions would be. This could potentially be pulled out from the SubPro report.
Team input:
* To further consider during the next call, but in general, whatever can be done to clarify language should be considered.
AOB
* None
Steven Chan
Senior Director, Policy Development Support & GNSO Relations
Internet Corporation for Assigned Names and Numbers (ICANN)
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536
Email: steve.chan at icann.org<mailto:steve.chan at icann.org>
Skype: steve.chan55
Mobile: +1.310.339.4410
Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=jLNFXvpu9gNdUeHi-G6sjWNCF9w4_AwhzzUDFZy2elE&s=o7Auz997kA-HPv9PHJCjFVZw7Pgo8krw4MxfqCwBrIU&e=>
Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGNSO&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=jLNFXvpu9gNdUeHi-G6sjWNCF9w4_AwhzzUDFZy2elE&s=kWw4fQPNjw2lVKy1UjTxS2F0BmjEAzaDFWNmsYywbmE&e=>
Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_group-2Dactivities_calendar&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=jLNFXvpu9gNdUeHi-G6sjWNCF9w4_AwhzzUDFZy2elE&s=-L6chFfv0OperrXHHpTF722WnH3FZIutn4cS16IvpOg&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20230202/27dca8bb/attachment-0001.html>
More information about the Gnso-epdp-idn-team
mailing list