Re: [Gnso-epdp-idn-team] Proposed Agenda - IDN EPDP Meeting #44 - Thursday 28 July 2022 at 13:30 UTC
A few additional comments on 2.3 re: use of “primary label” * Some questions I reckon we will face throughout: what is the “primary” label? what function does it serve? should we use such nomenclature? … some background notes: * When we talk about variants in a set, it is important to note which of all labels is the source for variant label calculation, or as we have adopted: the primary label. As a way of context, first, the variant relationship between two code points must satisfy the symmetrical property (there are other properties, but not relevant to this topic). This means, if ‘A’ is a variant of ‘B’, then ‘B’ is a variant of ‘A’. Second, any variant relationship is also assigned a disposition value: allocatable or blocked. The disposition value is unidirectional. Which means, a variant relationship could yield an ‘allocatable’ variant in one direction (e.g., A-->B: allocatable), but a ‘blocked’ variant in the other direction (e.g., B-->A: blocked). These rules are encoded in the LGR. * As we progress in our deliberations about the lifecycle of gTLDs it is important to understand (and remember) how the various variant labels and disposition values came to be (to discern which ones are allocatable/withheld or blocked). However, I believe we need to remain open (or at least give thoughtful consideration) to cases where one TLD label in the set needs to be handled separately e.g., retirement, and the implications of this one change applies to the rest of the labels in the set. For instance, what if the registry operator wants to retire the “primary” label and continue to operate the rest of variants. In this case, it would be unwise, perhaps, to re-assign the attribute of “primary” to another label in the set, because that might change the profile of the set as a whole (of course, this would depend what “primary” means and how it is used). * All I am saying is let’s be careful where and how we use the term “primary”. Perhaps this is a good test case for stress testing a la ccPDP4. Best, Dennis From: Gnso-epdp-idn-team <gnso-epdp-idn-team-bounces@icann.org> on behalf of Ariel Liang <ariel.liang@icann.org> Date: Monday, July 25, 2022 at 1:48 PM To: Emily Barabas <emily.barabas@icann.org>, "gnso-epdp-idn-team@icann.org" <gnso-epdp-idn-team@icann.org> Subject: [EXTERNAL] Re: [Gnso-epdp-idn-team] Proposed Agenda - IDN EPDP Meeting #44 - Thursday 28 July 2022 at 13:30 UTC Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Dear All, First, as a reminder – the joint ccPDP4 and IDN-EPDP meeting will take place tomorrow (Tue, 26 July at 14:00-15:30 UTC). We look forward to your participation! Second, as a refresher of last week’s meeting and a preview of the upcoming IDN-EPDP meeting on Thursday (see agenda below), leadership team and staff are proposing the following changes to the draft recommendations 2.3, 2.5, and 2.6, incorporating input received: Rec 2.3 (see p.2: https://docs.google.com/document/d/15YGISgNQYL_VfcVVZ6E97qbo42GPziP6x089bR3w...): · Summary of discussion – some members raised the concern that the “primary” label was not specified · Recommendation language: revised as “If the registry operator of an IDN gTLD changes its back-end registry service provider, that IDN gTLD and any additional delegated variant label(s) associated with that gTLD must also simultaneously transition to the new back-end registry service provider.” o This revision seeks to clarify the gTLD labels that are impacted by the transition of back-end registry service provider without the need to use the term “primary label” and “set”. · Rationale – replaced the last sentence with the following: “To that end, the transition to a new back-end registry service provider must apply to the primary gTLD and all of its delegated variant labels at the same time.” o This sentence seeks to explain, in general terms, the transition of back-end RSP simultaneously apply to the primary gTLD and all of its delegated variants. Rec 2.5 (see p.3: https://docs.google.com/document/d/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvUH...): · Summary of discussion – some members were unsure about adding the phrase “during the same round” at the end of the recommendation language, as the discussion about the process and timing of variant activation is still ongoing. · Recommendation language – no change to the original recommendation language (i.e., not adding “during the same round”) · Rationale part – add the following sentence at the beginning: “The EPDP Team noted SubPro PDP’s recommendation that future applications of new gTLDs ‘must be assessed in rounds’.” o This seeks to provide context that future new gTLD applications are expected to happen in rounds. Rec 2.6 (see p.3: https://docs.google.com/document/d/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvUH...): · Summary of discussion – divergence of opinion from RySG and ALAC regarding “ensuring a secure, stable, and consistent user experience” in the rationale · Recommendation language – no change · Rationale – replace the phrase “…with a view to ensuring a secure, stable, and consistent user experience” with “…to achieve the security, stability, and usability goals for IDN variants”. o This is the general goal of variant management as incorporated in the IDN-EPDP charter Best Regards, Ariel From: Gnso-epdp-idn-team <gnso-epdp-idn-team-bounces@icann.org> on behalf of Emily Barabas <emily.barabas@icann.org> Date: Monday, July 25, 2022 at 1:06 PM To: "gnso-epdp-idn-team@icann.org" <gnso-epdp-idn-team@icann.org> Subject: [Gnso-epdp-idn-team] Proposed Agenda - IDN EPDP Meeting #44 - Thursday 28 July 2022 at 13:30 UTC Dear all, Please find below the proposed agenda for our meeting on Thursday 28 July 2022 at 13:30 UTC. Kind regards, Ariel, Steve, and Emily IDN EPDP Meeting #44 Proposed Agenda 1. Roll Call & SOI (2 minutes) 2. Welcome & Chair Updates (5 mins) 3. Review Proposed Revisions to Recommendation 2.3 under Charter Question B2 [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/15YGISgNQYL_VfcVVZ6E97qbo42GPziP6x089bR3wgZw/edit__;!!PtGJab4!5fBDOTyR6u3-v3fy4WsfSCM3nsCfrLp4Qyf3JtxXaf0-nCdBAHE8SUGzZBaREX-HsQNjuS3sFoDshMl-77crtBE2mwzxSJw$>, and Recommendations 2.5 and 2.6 under Charter Question D1b (part 2) [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvUH5Sw/edit__;!!PtGJab4!5fBDOTyR6u3-v3fy4WsfSCM3nsCfrLp4Qyf3JtxXaf0-nCdBAHE8SUGzZBaREX-HsQNjuS3sFoDshMl-77crtBE2mwU8CM0$> (80 mins) 4. AOB (3 mins)
Hi Dennis, On 25.07.2022 21:46, Tan Tanaka, Dennis via Gnso-epdp-idn-team wrote:
A few additional comments on 2.3 re: use of “primary label”
* Some questions I reckon we will face throughout: what is the “primary” label? what function does it serve? should we use such nomenclature? … some background notes: * When we talk about variants in a set, it is important to note which of all labels is the source for variant label calculation, or as we have adopted: the primary label. As a way of context, first, the variant relationship between two code points must satisfy the symmetrical property (there are other properties, but not relevant to this topic). This means, if ‘A’ is a variant of ‘B’, then ‘B’ is a variant of ‘A’. Second, any variant relationship is also assigned a disposition value: allocatable or blocked. The disposition value is unidirectional. Which means, a variant relationship could yield an ‘allocatable’ variant in one direction (e.g., AàB: allocatable), but a ‘blocked’ variant in the other direction (e.g., BàA: blocked). These rules are encoded in the LGR. * As we progress in our deliberations about the lifecycle of gTLDs it is important to understand (and remember) how the various variant labels and disposition values came to be (to discern which ones are allocatable/withheld or blocked). However, I believe we need to remain open (or at least give thoughtful consideration) to cases where one TLD label in the set needs to be handled separately e.g., retirement, and the implications of this one change applies to the rest of the labels in the set. For instance, what if the registry operator wants to retire the “primary” label and continue to operate the rest of variants. In this case, it would be unwise, perhaps, to re-assign the attribute of “primary” to another label in the set, because that might change the profile of the set as a whole (of course, this would depend what “primary” means and how it is used).
This is a very good point. Especially with asymmetric disposition we have a real problem if a primary label is retired and the other variants are kept. There might arise a situation in which none of the remaining variants can be made primary, because it would entail one of the other existing variants to become blocked instead of allocatable. The question would then be * Do we allow a variant set to exist without a primary label? * Will retiring a primary label require the registry to select another primary label and thereby possibly force them to retire other variants together with the former primary label? Take the following quite simple example. Applied for primary label: bıß Allocatable Variants: biß, bıss, biss So, someone might have all four labels in the Root zone at some point. If they now retire the primary label bıß, the other three labels could not exist at the time (without bıß also existing). Case 1: biß is made new primary Consequence: bıss becomes a blocked variant. Case 2: bıss is made new primary Consequence: biß becomes a blocked variant. Case 3: biss is made a new primary Consequence: both bıss and biß become blocked variants. Even though the example is not very likely, it's certainly possible and in other scripts might be similar examples that are more likely. So, to summarise my points: * Initially, we need a primary label to determine the disposition value of all variants. * Retiring a primary label may cause problems and we need to decide how to deal with these problems. Best regards, Michael -- ____________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 44227 Dortmund Germany Dipl.-Informatiker Fon: +49 231 9703-0 Fax: +49 231 9703-200 Dr. Michael Bauland SIP: Michael.Bauland@knipp.de Software Development E-mail: Michael.Bauland@knipp.de Register Court: Amtsgericht Dortmund, HRB 13728 Chief Executive Officers: Dietmar Knipp, Elmar Knipp
I think the procedure of the retirement needs to have a check for the existence of the primary and if not - election of the new one. Maxim Alzoba On Jul 26, 2022, 09:42, at 09:42, Michael Bauland <michael.bauland@knipp.de> wrote:
Hi Dennis,
A few additional comments on 2.3 re: use of “primary label”
* Some questions I reckon we will face throughout: what is the “primary” label? what function does it serve? should we use such nomenclature? … some background notes: * When we talk about variants in a set, it is important to note which of all labels is the source for variant label calculation, or as we have adopted: the primary label. As a way of context, first, the variant relationship between two code points must satisfy the symmetrical property (there are other properties, but not relevant to this topic). This means, if ‘A’ is a variant of ‘B’, then ‘B’ is a variant of ‘A’. Second, any variant relationship is also assigned a disposition value: allocatable or blocked. The disposition value is unidirectional. Which means, a variant relationship could yield an ‘allocatable’ variant in one direction (e.g., AàB: allocatable), but a ‘blocked’ variant in the other direction (e.g., BàA: blocked). These rules are encoded in the LGR. * As we progress in our deliberations about the lifecycle of gTLDs it is important to understand (and remember) how the various variant labels and disposition values came to be (to discern which ones are allocatable/withheld or blocked). However, I believe we need to remain open (or at least give thoughtful consideration) to cases where one TLD label in the set needs to be handled separately e.g., retirement, and the implications of this one change applies to
On 25.07.2022 21:46, Tan Tanaka, Dennis via Gnso-epdp-idn-team wrote: the
rest of the labels in the set. For instance, what if the registry operator wants to retire the “primary” label and continue to
operate
the rest of variants. In this case, it would be unwise, perhaps,
to
re-assign the attribute of “primary” to another label in the set, because that might change the profile of the set as a whole (of course, this would depend what “primary” means and how it is
used).
This is a very good point. Especially with asymmetric disposition we have a real problem if a primary label is retired and the other variants are kept. There might arise a situation in which none of the remaining variants can be made primary, because it would entail one of the other existing variants to become blocked instead of allocatable.
The question would then be * Do we allow a variant set to exist without a primary label? * Will retiring a primary label require the registry to select another primary label and thereby possibly force them to retire other variants together with the former primary label?
Take the following quite simple example. Applied for primary label: bıß Allocatable Variants: biß, bıss, biss
So, someone might have all four labels in the Root zone at some point.
If they now retire the primary label bıß, the other three labels could not exist at the time (without bıß also existing).
Case 1: biß is made new primary Consequence: bıss becomes a blocked variant.
Case 2: bıss is made new primary Consequence: biß becomes a blocked variant.
Case 3: biss is made a new primary Consequence: both bıss and biß become blocked variants.
Even though the example is not very likely, it's certainly possible and
in other scripts might be similar examples that are more likely.
So, to summarise my points: * Initially, we need a primary label to determine the disposition value
of all variants. * Retiring a primary label may cause problems and we need to decide how
to deal with these problems.
Best regards,
Michael
-- ____________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 44227 Dortmund Germany
Dipl.-Informatiker Fon: +49 231 9703-0 Fax: +49 231 9703-200 Dr. Michael Bauland SIP: Michael.Bauland@knipp.de Software Development E-mail: Michael.Bauland@knipp.de
Register Court: Amtsgericht Dortmund, HRB 13728
Chief Executive Officers: Dietmar Knipp, Elmar Knipp _______________________________________________ Gnso-epdp-idn-team mailing list Gnso-epdp-idn-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-idn-team
And this is the question I post to this group. Do we need to always have a label designated as “primary”, and if so, what function will it serve? My current thinking is that the primary label serves its purpose to determine the set of ALL variant labels — allocatable and blocked. Beyond this point the set is established (disposition values are captured), and so, I would argue, a “primary” label no longer have utility (other than a data point to indicate how the set was formed, and/or potential re-calculation due to rz-lgr changes). Each applied-for/delegated label should have equal standing in the set, IMO. But perhaps I am missing something. Dennis From: Gnso-epdp-idn-team <gnso-epdp-idn-team-bounces@icann.org> on behalf of Maxim Alzoba <m.alzoba@gmail.com> Date: Tuesday, July 26, 2022 at 3:54 AM To: Michael Bauland <Michael.Bauland@knipp.de> Cc: "gnso-epdp-idn-team@icann.org" <gnso-epdp-idn-team@icann.org> Subject: [EXTERNAL] Re: [Gnso-epdp-idn-team] primary labels and consequences of retiring them Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I think the procedure of the retirement needs to have a check for the existence of the primary and if not - election of the new one. Maxim Alzoba On Jul 26, 2022, at 09:42, Michael Bauland <michael.bauland@knipp.de<mailto:michael.bauland@knipp.de>> wrote: Hi Dennis, On 25.07.2022 21:46, Tan Tanaka, Dennis via Gnso-epdp-idn-team wrote: A few additional comments on 2.3 re: use of “primary label” * Some questions I reckon we will face throughout: what is the “primary” label? what function does it serve? should we use such nomenclature? … some background notes: * When we talk about variants in a set, it is important to note which of all labels is the source for variant label calculation, or as we have adopted: the primary label. As a way of context, first, the variant relationship between two code points must satisfy the symmetrical property (there are other properties, but not relevant to this topic). This means, if ‘A’ is a variant of ‘B’, then ‘B’ is a variant of ‘A’. Second, any variant relationship is also assigned a disposition value: allocatable or blocked. The disposition value is unidirectional. Which means, a variant relationship could yield an ‘allocatable’ variant in one direction (e.g., AàB: allocatable), but a ‘blocked’ variant in the other direction (e.g., BàA: blocked). These rules are encoded in the LGR. * As we progress in our deliberations about the lifecycle of gTLDs it is important to understand (and remember) how the various variant labels and disposition values came to be (to discern which ones are allocatable/withheld or blocked). However, I believe we need to remain open (or at least give thoughtful consideration) to cases where one TLD label in the set needs to be handled separately e.g., retirement, and the implications of this one change applies to the rest of the labels in the set. For instance, what if the registry operator wants to retire the “primary” label and continue to operate the rest of variants. In this case, it would be unwise, perhaps, to re-assign the attribute of “primary” to another label in the set, because that might change the profile of the set as a whole (of course, this would depend what “primary” means and how it is used). This is a very good point. Especially with asymmetric disposition we have a real problem if a primary label is retired and the other variants are kept. There might arise a situation in which none of the remaining variants can be made primary, because it would entail one of the other existing variants to become blocked instead of allocatable. The question would then be * Do we allow a variant set to exist without a primary label? * Will retiring a primary label require the registry to select another primary label and thereby possibly force them to retire other variants together with the former primary label? Take the following quite simple example. Applied for primary label: bıß Allocatable Variants: biß, bıss, biss So, someone might have all four labels in the Root zone at some point. If they now retire the primary label bıß, the other three labels could not exist at the time (without bıß also existing). Case 1: biß is made new primary Consequence: bıss becomes a blocked variant. Case 2: bıss is made new primary Consequence: biß becomes a blocked variant. Case 3: biss is made a new primary Consequence: both bıss and biß become blocked variants. Even though the example is not very likely, it's certainly possible and in other scripts might be similar examples that are more likely. So, to summarise my points: * Initially, we need a primary label to determine the disposition value of all variants. * Retiring a primary label may cause problems and we need to decide how to deal with these problems. Best regards, Michael
Hi Dennis, all Thank you for raising the question about what we mean when we use the term ‘primary’ and the potential consequences associated with such a designation. Michael has also provided some useful input on this point. As our discussions have evolved we have referred to the ‘primary’ to make a distinction between the IDN gTLD being applied for and the associated variant labels that are either allocatable or blocked that comprise an IDN variant ‘set’. However, our discussions can be complicated, particularly as we all have different levels of understanding of IDNs, and we use words that some might consider technically incorrect, but I believe have become commonly understood terms or phrases within our group, to help distinguish a point that someone/we’re trying to address or make. I agree that the Team does need to discuss what is the most accurate terminology that we should use to describe what we intend with our recommendations. The leadership team is aware that this is a concern and have discussed developing a glossary, which I think will be helpful. In addition, we also recognize that the draft text that we have circulated to date is not consistent in the use of terms or phrases and this is something we are also looking to address. So, I want to acknowledge your concerns, but for now I would like to park these for later discussion/consideration by the Team to give the Leadership Team some time to look into how best to address the issue. Thanks Donna From: Gnso-epdp-idn-team <gnso-epdp-idn-team-bounces@icann.org> On Behalf Of Tan Tanaka, Dennis via Gnso-epdp-idn-team Sent: Tuesday, July 26, 2022 8:34 AM To: m.alzoba@gmail.com; Michael.Bauland@knipp.de Cc: gnso-epdp-idn-team@icann.org Subject: Re: [Gnso-epdp-idn-team] primary labels and consequences of retiring them Caution: This email is from an external sender. Please do not click links or open attachments unless you recognize the sender and know the content is safe. Forward suspicious emails to isitbad@. And this is the question I post to this group. Do we need to always have a label designated as “primary”, and if so, what function will it serve? My current thinking is that the primary label serves its purpose to determine the set of ALL variant labels — allocatable and blocked. Beyond this point the set is established (disposition values are captured), and so, I would argue, a “primary” label no longer have utility (other than a data point to indicate how the set was formed, and/or potential re-calculation due to rz-lgr changes). Each applied-for/delegated label should have equal standing in the set, IMO. But perhaps I am missing something. Dennis From: Gnso-epdp-idn-team <gnso-epdp-idn-team-bounces@icann.org<mailto:gnso-epdp-idn-team-bounces@icann.org>> on behalf of Maxim Alzoba <m.alzoba@gmail.com<mailto:m.alzoba@gmail.com>> Date: Tuesday, July 26, 2022 at 3:54 AM To: Michael Bauland <Michael.Bauland@knipp.de<mailto:Michael.Bauland@knipp.de>> Cc: "gnso-epdp-idn-team@icann.org<mailto:gnso-epdp-idn-team@icann.org>" <gnso-epdp-idn-team@icann.org<mailto:gnso-epdp-idn-team@icann.org>> Subject: [EXTERNAL] Re: [Gnso-epdp-idn-team] primary labels and consequences of retiring them Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I think the procedure of the retirement needs to have a check for the existence of the primary and if not - election of the new one. Maxim Alzoba On Jul 26, 2022, at 09:42, Michael Bauland <michael.bauland@knipp.de<mailto:michael.bauland@knipp.de>> wrote: Hi Dennis, On 25.07.2022 21:46, Tan Tanaka, Dennis via Gnso-epdp-idn-team wrote: A few additional comments on 2.3 re: use of “primary label” * Some questions I reckon we will face throughout: what is the “primary” label? what function does it serve? should we use such nomenclature? … some background notes: * When we talk about variants in a set, it is important to note which of all labels is the source for variant label calculation, or as we have adopted: the primary label. As a way of context, first, the variant relationship between two code points must satisfy the symmetrical property (there are other properties, but not relevant to this topic). This means, if ‘A’ is a variant of ‘B’, then ‘B’ is a variant of ‘A’. Second, any variant relationship is also assigned a disposition value: allocatable or blocked. The disposition value is unidirectional. Which means, a variant relationship could yield an ‘allocatable’ variant in one direction (e.g., AàB: allocatable), but a ‘blocked’ variant in the other direction (e.g., BàA: blocked). These rules are encoded in the LGR. * As we progress in our deliberations about the lifecycle of gTLDs it is important to understand (and remember) how the various variant labels and disposition values came to be (to discern which ones are allocatable/withheld or blocked). However, I believe we need to remain open (or at least give thoughtful consideration) to cases where one TLD label in the set needs to be handled separately e.g., retirement, and the implications of this one change applies to the rest of the labels in the set. For instance, what if the registry operator wants to retire the “primary” label and continue to operate the rest of variants. In this case, it would be unwise, perhaps, to re-assign the attribute of “primary” to another label in the set, because that might change the profile of the set as a whole (of course, this would depend what “primary” means and how it is used). This is a very good point. Especially with asymmetric disposition we have a real problem if a primary label is retired and the other variants are kept. There might arise a situation in which none of the remaining variants can be made primary, because it would entail one of the other existing variants to become blocked instead of allocatable. The question would then be * Do we allow a variant set to exist without a primary label? * Will retiring a primary label require the registry to select another primary label and thereby possibly force them to retire other variants together with the former primary label? Take the following quite simple example. Applied for primary label: bıß Allocatable Variants: biß, bıss, biss So, someone might have all four labels in the Root zone at some point. If they now retire the primary label bıß, the other three labels could not exist at the time (without bıß also existing). Case 1: biß is made new primary Consequence: bıss becomes a blocked variant. Case 2: bıss is made new primary Consequence: biß becomes a blocked variant. Case 3: biss is made a new primary Consequence: both bıss and biß become blocked variants. Even though the example is not very likely, it's certainly possible and in other scripts might be similar examples that are more likely. So, to summarise my points: * Initially, we need a primary label to determine the disposition value of all variants. * Retiring a primary label may cause problems and we need to decide how to deal with these problems. Best regards, Michael
participants (4)
-
Donna＠registry.godaddy -
Maxim Alzoba -
Michael Bauland -
Tan Tanaka, Dennis