[Gnso-epdp-idn-team] Notes and Action Items - IDNs EPDP Meeting #91 - 10 August 2023
Justine Chew
justine.chew.icann at gmail.com
Fri Aug 11 23:55:23 UTC 2023
Excellent note-taking, thank you Dan!
Kind regards,
Justine
On Fri, 11 Aug 2023 at 22:16, Daniel Gluck <daniel.gluck at icann.org> wrote:
> Hi All,
>
>
>
> Please find below the notes and action items from the 10 August 2023 IDNs
> EPDP meeting #91 <https://community.icann.org/x/woyZDg> at 12:00 UTC.
>
>
>
> Best regards,
> Ariel, Steve, and Dan
>
>
>
>
>
> *ACTION ITEMS*
>
>
>
> 1. Leadership will review the options to address ICANN Org comments on
> Implementation Guidance 8.9.
> 2. For Recommendation 8.11, The team will work on drafting
> implementation guidance on the request to remove a variant from the root
> zone which would require a request or a transition plan submitted to ICANN
> org for consideration to finalize the request.
> 3. The comment on Rec 8.12 will be accepted without objection. EPDP
> Support Staff will revise the Recommendation to say ““In the event a TLD is
> removed from the root zone the rest of the variant label set (if any) must
> be removed from the root zone.”
> 4. The comment for I.G. 9.4 will be accepted, pending the changes to
> the language below:
>
> a. Starting text (9.4.3) “from “rejected” to “withheld-same-entity”:
> This transition happens when the rejected state of a label comes off; such
> a variant label can be treated as any other withheld-same-entity label.”
>
> b. New text (9.4.3) “from “rejected” to “withheld-same-entity”: This
> transition happens when the "the condition which led to the rejection of
> the label no longer applies; such a variant label can be treated as any
> other withheld-same-entity label.”
>
> 1. Leadership will develop revised text for the Global Change based on
> the following principles:
>
>
> 1. Delete “IDN”
> 2. Delete “2012 Round”
> 3. Use “existing” when referring to all of the gTLDs that have
> been delegated in the root zone
> 4. Remove the statement led by the asterisk and emphasize the
> indeed messaging in rationale
>
>
>
>
>
> *NOTES*
>
>
>
> - Roll Call and SOI Updates (2 min)
>
>
> - No updates
>
>
> - Welcome and Chair Updates (5 min)
>
>
> - Chair provided an introduction for the call and provided an update
> that the 24 August call will be canceled due to conflict with the GNSO
> council call at the same time.
> - Staff also reminded the team that there was draft text on Phase 2
> preliminary recommendations submitted to the email list for their review by
> 22 August.
>
>
> - Continue with Public Comment Review, from Rec 8.8 (55 min)
>
>
> - Starting with I.G. 8.9, the team discussed comments from ICANN org
> relating to the RZ-LGR Procedure with a proposed team action of amending
> the linked Recommendation 8.7 from EPDP IDN Leadership. This could happen
> in different ways, including a disclaimer, but all have the goal of
> potentially softening language.
>
>
> - ACTION ITEM: Leadership will review the options to address ICANN Org
> comments on I.G. 8.9
>
>
> - On Recommendation 8.11, ICANN Org provided a comment, listed under
> significant change required due to the language used of “the voluntary
> review of a variant label from the root zone”.
>
>
> - One participant discussed the comment and made a distinction between
> registrations at the second level that are short-term, so there is no
> consequence to removing one.
> - In chat another mentioned “A transition plan is a sensible ask
> that the RO would need to provide describing how they plan to minimize
> impact to registrants. If existing registrations exist of course.”
>
>
> 1. The chair discussed that if a singular variant label is removed, do
> you have to remove the other labels? There are more discussions to be had,
> including if there should be a recommendation or implementation guidance.
> Whatever the current practice is would be recommended to continue for IDNs.
>
>
> - Another participant shared that the removal of a label should be in
> its own recommendation. There would also be possible consequences regarding
> redelegation. There was also additional support shared for a transition
> plan for supporting existing registrants.
>
>
> 1. In chat, they mentioned “such removal could happen due to a state
> deciding to remove support of a script (I know at least one country moving
> from Cyrillic based script to Latin based one for a state supported
> language)”
>
>
> - A participant mentioned the comment from Org seems a bit strange as
> the variant TLD should not have different domain name registration from the
> primary
>
>
> 1. A response from a different participant stated that variant TLDs
> don’t need to have the same domain name registrations as the primaries.
> There is a SubPro recommendation to that effect.
>
>
> 1. “SubPro recommendation: Recommendation 25.8: Second-level labels
> derived from Recommendation 25.6 or Recommendation 25.7 are not required to
> act, behave, or be perceived as identical.”
> 2. This was seconded by a participant, but a different
> participant disagreed with this as it would violate the same entity rule
>
>
> - It was agreed that the registrant has to be the same entity, but it
> is up to the registrant if the domain names should behave the same way.
>
>
> 1. The chair mentioned that it is possible to un-delegate or remove a
> variant label from a set and there should be no effect on the domain names
> registered under the primary gTLD. They also asked if the team would
> support drafting implementation guidance on the request to remove a variant
> from the root zone, which would require a request or a transition plan
> submitted to ICANN org for consideration.
>
>
> - ACTION ITEM: The team will work on drafting implementation guidance
> on the request to remove a variant from the root zone which would require a
> request or a transition plan submitted to ICANN org for consideration to
> finalize the request.
>
>
> 1. The process for re-activating a variant TLD could necessitate a
> cool-down period
>
>
> - Some comments in chat included
>
>
> 1. “We don't have a separate process for activating variant TLDs, so I
> don't know why we would have a separate process for RE-activating a variant
> TLD. Cooling period is interesting.”
> 2. “[The] transition plan simply needs to include
> the quiet period... within the sunset arrangements?”
>
>
> - A scenario was proposed to the team in chat
>
>
> 1. “RO1 requests un-delegation which is granted and executed, then RO2
> acquires RO1’s assets and wants the TLD variant that was undelegated just a
> few months back”
>
>
> 1. The chair shared that the registrant would have to re apply, but
> since this would be an edge case it shouldn’t be a major concern.
>
>
> - What about the costs of reapplying for the formerly removed TLD?
>
>
> 1. The registrant will have to pay again for the application
>
>
> - Moving to the supporting comment from ICANN org on Rec. 8.12 and
> there were no objections to accepting the change from ICANN org
>
>
> - ACTION ITEM: The comment on Rec 8.12 will be accepted without
> objection. EPDP Support Staff will revise the Recommendation to say ““In
> the event a TLD is removed from the root zone the rest of the variant label
> set (if any) must be removed from the root zone.”
>
> o On I.G. 9.4, there was a discussion about the usage of “applies” vs
> “applicable” in the place of “relevant” in the I.G., with “applies” being
> chosen. There was also support for removing “is” in the text. Other than
> that, no objections to accepting the ICANN org comment.
>
> § ACTION ITEM: The comment for I.G. 9.4 will be accepted, pending the
> following changes to the language:
>
> · Starting text (9.4.3) “from “rejected” to
> “withheld-same-entity”: This transition happens when the rejected state of
> a label comes off; such a variant label can be treated as any other
> withheld-same-entity label.”
>
> · New text (9.4.3) “from “rejected” to “withheld-same-entity”:
> This transition happens when the "the condition which led to the rejection
> of the label no longer applies; such a variant label can be treated as any
> other withheld-same-entity label.”
>
> o ICANN staff then walked the participants through the “Other” tab at
> the end of the public comment tool. On this page there are 8 comments
>
> § There were no comments from the Team on this page
>
> o The chair congratulated the team on making it through all public
> comments and discussed that the Leadership will go through the document and
> make applicable changes.
>
> - Discuss Global Change Around “Existing”, “IDN”, “Delegated” (55 min)
>
>
> - ICANN org provided a background on the Global Change, along with
> some potential language generated by Leadership and action items for the
> team.
>
>
> - Leadership was charged with developing revised text for the Global
> Change based on the following clauses:
>
>
> 1. They will consider whether, when, and where to use the phrase
> “existing IDN gTLD from the 2012 round” and,
> 2. Consider the approach with regard to the statement led by
> the asterisk “* Preliminary Recommendation xx only impacts existing IDN
> gTLDs from the 2012 round”.
>
>
> 1. The language included deleting “IDN” and “2012 round”. It also
> includes the use of “existing” when referring to all of the gTLDs that have
> been delegated in the root zone and removing the statement led by asterisk
> and emphasizing similar messaging in the rationale. These were undertaken
> for various reasons, including future-proofing updates to the RZ-LGR,
> accommodate current gTLDs in the root zone, limit misinterpretation, and
> remain in the boundaries of the recommendations.
>
>
> - Examples were provided for recommendations 1.1, 2.1, 3.10, and 3.11.
> - Exceptions were also provided for recommendations 3.14 and
> 3.15.
>
>
> 1. The rationale for these exceptions included compensating a specific
> group of 2012 applicants that included Arabic and Chinese gTLD Registry
> Operators that have been unable to fulfill their interests or needs due to
> the unavailability of variant labels, and to remain consistent with RySG
> input.
>
>
> - There was also rationale provided for specific parked
> recommendations (recommendations 7.3 and 7.4) that are not applicable to be
> changed at this time due to public comment from ICANN org and CCWP-HR that
> would require substantive amendments.
>
>
> - The chair shared that they are “Looking for ‘in principle’ support
> (or not) that would allow us to develop revised text that will be sent to
> the group for the two week consideration period.”
>
>
> - Assent was given in chat for in principle support
> - ACTION ITEM: Leadership will develop revised text for the
> Global Change based on the following principles:
>
>
> 1. Delete “IDN”
> 2. Delete “2012 Round”
> 3. Use “existing” when referring to all of the gTLDs that
> have been delegated in the root zone
> 4. Remove the statement led by the asterisk and emphasize the
> indeed messaging in rationale
>
>
> - AOB (3 minutes)
>
>
> - The chair once again congratulated the team, previewed the second
> level charter questions for the next meeting, and adjourned the meeting
>
>
> _______________________________________________
> Gnso-epdp-idn-team mailing list
> Gnso-epdp-idn-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-idn-team
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20230812/5a89f95b/attachment-0001.html>
More information about the Gnso-epdp-idn-team
mailing list