Re: [Gnso-epdp-idn-team] Confirm Edits: Group 2 Charter Questions Related to "Same Entity" Principle at Top-Level
Ariel, et al Members of the RySG reviewed the proposed revision to the Rationale for Recommendation 2.6 which incorporates a reference to “usability goals for IDN variants”. We consider this addition to be inappropriate for two reasons. First, the language in the rationale should not be used to expand the intent (or scope) of the recommendation itself. In this case, Recommendation 2.6 refers to the technical and operational competence of a TLD registry operator, therefore the corresponding rationale should elaborate on the same terms. Second, the term “usability goals” is not defined which, if taken into consideration, can lead to subjective outcomes from an evaluation standpoint, which can impact predictability of the evaluation process. Therefore, the RySG respectfully rejects the latest revision to the language in the section Rationale for Recommendation 2.6. At the same time, we provide the following edits. Recommendation 2.6: The applicant will be required, as part of the application process, to explain the reason(s) why it needs to activate the applied-for variant label(s). In addition, the applicant will be required to demonstrate their ability to manage the primary IDN gTLD and the applied-for variant label(s) as a set from both a technical and operational perspective. Rationale for Recommendation 2.6: As IDN gTLDs and variant labels that are considered a set are yet to be delegated and operated at the root zone level, there is uncertainty about how athe set of variant TLDs will be managed and operated by athe registry operator from a technical and user perspective. Therefore, it will be important that applicants are able to explain their need for a set of IDN variant TLD label(s) as well as to demonstrate their technical capability to operate and manage the set of TLDs. Consequently Therefore, the applicant will be required to respond to additional application questions to address why they seek to activate those variant label(s) in addition to the primary new gTLD (i.e., necessity and expected usage of the variant labels), as well as how it plans to manage the set technically and operationally to achieve the security, stability, and usability goals for IDN variants as well as how it plans to manage the set operationally, with a view to ensuring a secure, stable, and consistent user experience. The applicant’s response to these questions is expected to be a critical component in the evaluation process. Evaluators with requisite expertise are expected to assess these responses. In addition, we ask the IDN EPDP working group to consider removing, or clarifying, the last two sentences (in green). They seem editorial in nature, and we are unsure as to what specifically these will accomplish. With respect to “The applicant’s response to these questions is expected to be a critical component in the evaluation process” Is the objective to promote IDN variant management competence questions over other aspects of the application? If the answer is no, then we don’t understand the need to make such an observation i.e., “critical component”. With respect to “Evaluators with requisite expertise are expected to assess these responses”, the RySG believes is a redundant and unnecessary statement as we expect that every step of the application process is undertaken in a professional and competent manner. However, if the intent is to provide instructions to the implementation team i.e., to seek ad hoc expertise, then we suggest making that clarification. The RySG does not have additional comments of the other remaining items. We are happy to continue this conversation over the course of the next working group meeting. Best, Dennis, on behalf the RySG IDN EPDP members From: Ariel Liang <ariel.liang@icann.org> Date: Friday, August 12, 2022 at 2:39 PM To: Dennis Tan Tanaka <dtantanaka@verisign.com>, "gnso-epdp-idn-team@icann.org" <gnso-epdp-idn-team@icann.org> Subject: [EXTERNAL] Confirm Edits: Group 2 Charter Questions Related to "Same Entity" Principle at Top-Level 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, During its meeting on 28 July<https://secure-web.cisco.com/1D9WAeo4A7tGzNRh7jMth-JcnjcXnvGtqYuUYgY8DQKQmJ1HbUZ_F78x5s15YF_HgVAPZVUrqGppq-hZQwU27_iTXQ6OxJv1W0U1OWB-_tEADI82dp0QnAgt_52TcfNUAGyQG-m5dQscTHTHJGmaY0Qz8ksvX4R4KooZJUY0ntNP1Z3frhRYqagYRm1k2demR_rGZlJYGlpxBGBvJhil7pTsf67Rn1eE9zaBS9Cwox92ljHliXcpWMEZRxSyGuT9K/https%3A%2F%2Fcommunity.icann.org%2Fx%2FJgYVD>, the EPDP Team discussed the input (mainly from RySG) for the outcome language of Group 2 charter questions. Members had preliminary agreement on the suggested edits discussed during the call. Since some members were not be able to make it to the 28 July call, staff are circulating the suggested edits for your review / confirmation. If no objection to the edits by EOB Friday, 19 August, we will regard these outcome languages stable. · Charter Question B2, Recommendation 2.3 and Rationale (p.2): https://docs.google.com/document/d/15YGISgNQYL_VfcVVZ6E97qbo42GPziP6x089bR3w... · Charter Question D1b (Part 2), Rationale for Recommendation 2.5 and 2.6 (p.3): https://docs.google.com/document/d/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvUH... Thank you for your review! Best Regards, Ariel From: "Tan Tanaka, Dennis" <dtantanaka@verisign.com> Date: Friday, July 15, 2022 at 4:30 PM To: Ariel Liang <ariel.liang@icann.org>, "gnso-epdp-idn-team@icann.org" <gnso-epdp-idn-team@icann.org> Subject: [Ext] Re: [Gnso-epdp-idn-team] Reminder: Draft Outcome: Group 2 Charter Questions Related to "Same Entity" Principle at Top-Level Ariel, et al On behalf the RySG members of the EPDP I would like to submit the following observations to the draft outcomes. · Summary of the redline: Adding clarifying language to reflect that allocation alone of a TLD to a same entity cannot guarantee avoiding denial of service failure mode. · Proposed language: Rationale for Recommendation 2.1: To support its consideration of charter question B1, the EPDP Team reviewed the SubPro PDP recommendation 25.5 and Staff Paper recommendation 2, as well as their rationale. The EPDP Team agreed that abiding by the “same entity” principle and having the same registry operator for all allocatable variant labels of an existing gTLD will help minimize, but not guarantee, the security risk associated with the “failure modes” – including denial of service and misconnection – when dealing with variant labels. Therefore, the EPDP Team affirms to extend the SubPro PDP and the Staff Paper recommendations to existing gTLDs. · Why the redline? Recommendation 2.1 is applied at the top level, not at the domain name level. Making a TLD label allocatable to a single entity (or withheld) does not directly avoid the failure mode of denial of service. Even if the gTLD variant is activated into the root, an actual domain name (second level.variantTLD) needs to be registered and operated, in all variant TLDs. So, while it can help to minimize denial of service problem, it cannot guarantee it due to downstream actions (by other entities different than the registry operator) that need to be implemented. Therefore, the inclusion of a caveat. Related to this. For special purpose TLDs (brand, geo, community based) if the variant set is held to the same requirements, then it is possible that allocatable variants do not meet the same eligibility requirements as the primary label (for example, a trademark record). Avoiding denial of service due to an inactive TLD variant (in this case) is not only improbable, but impossible. · Summary of the redline: a registry operator should not be expected to ensure consistent user experience because it does not host or manage content (e.g. website, email services). · Rationale for Recommendation 2.6: As IDN gTLDs and variant labels that are considered a set are yet to be delegated and operated at the root zone level, there is uncertainty about how the set will be managed and operated by the registry operator from a technical and user perspective. Therefore, it will be important that applicants are able to explain their need for a set of IDN variant label(s) as well as demonstrate their technical capability to operate and manage the set. Therefore, the applicant will be required to respond to additional application questions to address why they seek to activate those variant label(s) in addition to the primary new gTLD (i.e., necessity and expected usage of the variant labels), as well as how it plans to manage the set operationally, with a view to ensuring a secure, stable, and consistent user experience. The applicant’s response to these questions is expected to be a critical component in the evaluation process. Evaluators with requisite expertise are expected to assess these responses. · Why the redline? While the language is in the rationale and not the draft recommendation, it may be misconstrued in an implementation guideline. We are far away from discussing operational requirements, but the suggestion that a registry operator should be expected to “manage” and “ensure” a “consistent user experience”, we think it may be misleading. We suggest removing that sentence from the rationale which does not affect the overall intent. · Summary of the redline: Minor change for consistency in terminology. · Recommendation 2.3: If the registry operator operating a variant gTLD label changes its back-end registry service provider, all the variant gTLD label(s) in the set must also switch transition to the same new back-end registry service provider. · Why the redline? Harmonizing language with MSA change process [secure-web.cisco.com]<https://secure-web.cisco.com/1Bro8B5l_Wcw-ezqU1OiQcoObazPmJzwJpUWFjkiiXES00JXqtKgI2gVz_hD2sXstZm5_ldcDUgHHJswFa4JQxfOuyTD-tSJEf1mpWyvxHalSD72s_pziLy4RZD7Wg88_f75QkdAD03V8ed99QB1107S1_mMhQ_0M56lWRu5kxWY-xuXzCpiJ_54AdTbxgTZioJy1VY2tTqedXvux8cLXGwLD65rJDWvGiQenDHZHF9712hdTfQjq8aQTGC4tNRx2/https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fsecure-web.cisco.com%2F17PTWZSoYgDuVsWnubBEirA3cdXcqCb3xaJvHUco0vIFE1JznqamjdBb352P4KjBxpAuek6hCj41p3O8PuxP9PM79-0BPFb5L7RGgGbfTTiXelonTZdunNe_W5PB0ASOjWhihZyP_riulkqkwG0aSheBh8C8EL5ZSdHLHoL9M-PsZBj9LUbBvCzKQOsdRqirobmmtSBBiaNZBcSJLwJhuMtIIonNwaAL1cJi1dslnQIbkg1YPz3Exx0LsSGSN5CUQ%2Fhttps%2A3A%2A2F%2A2Fwww.icann.org%2A2Fresources%2A2Fmaterial-subcontracting-arrangement__%3BJSUlJSU%21%21PtGJab4%218c3Wua0ZIsCJQHOFJY_Hi171n9LVSKFXACciHXiBvFTWzNf8ZwMMPgLO40g-0oKSqBsyaCSdL8dpYhShiwllm2lE0Osb%24>, which uses the term “transition”. One additional note. On draft recommendation 2.8 (B5: special purpose TLDs) I have shared the draft outcome with our colleagues in the Brand Registry Group and GeoTLD Group. I’m working with them to get their insights, so I’d like to ask for your patience while I compile their input. Thank you, Dennis, on behalf the RySG IDN EPDP members From: Gnso-epdp-idn-team <gnso-epdp-idn-team-bounces@icann.org> on behalf of Ariel Liang <ariel.liang@icann.org> Date: Thursday, July 14, 2022 at 12:04 PM To: "gnso-epdp-idn-team@icann.org" <gnso-epdp-idn-team@icann.org> Subject: [EXTERNAL] [Gnso-epdp-idn-team] Reminder: Draft Outcome: Group 2 Charter Questions Related to "Same Entity" Principle at Top-Level 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, This is the final reminder for reviewing the draft outcome language for Group 2 charter questions by EOB Friday, 15 July (initial deadline extended by one week). Please see details below. FYI - the ALAC Team informed staff that they agree with the draft language for those questions. Best Regards, Ariel From: Ariel Liang <ariel.liang@icann.org> Date: Friday, June 24, 2022 at 11:43 AM To: "gnso-epdp-idn-team@icann.org" <gnso-epdp-idn-team@icann.org> Subject: Draft Outcome: Group 2 Charter Questions Related to "Same Entity" Principle at Top-Level Dear All Please find the draft outcome language for Group 2 charter questions related to “same entity” principle at the top-level, which are: · B1, B2, B3, B5: https://docs.google.com/document/d/15YGISgNQYL_VfcVVZ6E97qbo42GPziP6x089bR3w... [docs.google.com]<https://secure-web.cisco.com/125QVY2mWi6jyMF5qSWVo_aIiWbivCcQNGcDg4vsmBBg2a2Q4t3nk_roJIxw6Mgkq_S0Hk96rftyP4vM6UKMz-OpaULPw4A0rFL2Hm4Z0lvuKNAhNBWbxJGNWe_3CWaOAh2wOAsnUbFr06Yf79h62LQMN64T-fdQBjhgjUBXXGWVRAyqBMVKek_iHFtNTicyAhGB2RUjdtlSYXrtlJ1y9kFLUphxmC53IHAT8KKnTxWiEmMeGD0VFs7jmJg_HyRqA/https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdocs.google.com%2Fdocument%2Fd%2F15YGISgNQYL_VfcVVZ6E97qbo42GPziP6x089bR3wgZw%2Fedit%3Fusp%3Dsharing__%3B%21%21PtGJab4%218c3Wua0ZIsCJQHOFJY_Hi171n9LVSKFXACciHXiBvFTWzNf8ZwMMPgLO40g-0oKSqBsyaCSdL8dpYhShiwllm-8sFIOs%24> · D1a, D1b (Part 2): https://docs.google.com/document/d/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvUH... [docs.google.com]<https://secure-web.cisco.com/1subCSwwrqimEMVMn-UKhDQDtVB11pJDsEcTHLRPJmt3aieu0smxUoi5hMHj_oIdL1WYBC3fELaFhNaggiYVrz9G8_3Dbk1w6ozBYU4gdeIxEOCqQG3skpynDBM6o743OJ3ja8j-WAz-_fhkyzbeRXZf46O_Zdr1Y-FzMOup_cBiW6h5RkBN4g0bfrPpd-85JonoGmK8N9u4QEv3krSioU_n5fDJ2u8GtnpdFCm-1eJ4T4-jwjauSYjv3ZXtte9V_/https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdocs.google.com%2Fdocument%2Fd%2F1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvUH5Sw%2Fedit%3Fusp%3Dsharing__%3B%21%21PtGJab4%218c3Wua0ZIsCJQHOFJY_Hi171n9LVSKFXACciHXiBvFTWzNf8ZwMMPgLO40g-0oKSqBsyaCSdL8dpYhShiwllmxcb5Nox%24> Both documents are also posted on the wiki page here: https://community.icann.org/x/XwyHCg [secure-web.cisco.com]<https://secure-web.cisco.com/12gAmWA9f-L3J1E-FfuWRHTwT1Awve1kIy7v1ecTEtezNzHKAw1BtRq08Xn9VA8ySVOCjyG-I5Rs8rI3KOqOdfBaN2UeXuEM31JO_Jb7tpj9NPyJwTk8Up77JMjIIfhRXr_mrQkDq1plktIOk8aSsox6vAy98ItRJ6tr6Y6S8xLlnrS6ucjAXk4leLF1I3AMrH4ZLpi86vrEBlLi84z1Yd8GUP3sWjGvuMrIV-rpY-L7Yweu2BqTw19H5UWshaoZF/https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fsecure-web.cisco.com%2F1cLkZefuhXu_uH3vPKV-WqdDsF3bAzHFSuVy6oxj5LpOcybpNP4PyqXxwdzXfKE839qWUKiXL4Tac845XODFW9zsz-2JTwMygfJszPmKDuLAJup98RKhMiPeOff-kGqgdD4cKTDFD7L0B-9HvQoE_fGIjrTbxPFuTcTETGelO62_PEs9hq2SqTx0oyTv21YDmCba0hl6L1fsggbDua02iAwynycwUCw8SQ3boexaJTHDEqxtRlrTNkmGmyoakpGkF%2Fhttps%2A3A%2A2F%2A2Fcommunity.icann.org%2A2Fx%2A2FXwyHCg__%3BJSUlJSU%21%21PtGJab4%218c3Wua0ZIsCJQHOFJY_Hi171n9LVSKFXACciHXiBvFTWzNf8ZwMMPgLO40g-0oKSqBsyaCSdL8dpYhShiwllmxDegkHS%24>. Following the agreed format, the draft outcome language includes the following components: · Brief answer to the charter question · Recommendations and implementation guidance · Rationale for recommendations and implementation guidance Please note that for charter question D1b Part 1 (related to the process by which an existing TLD registry operator seeks to activate variants) has not be addressed; it depends on the survey responses from the Arabic/Chinese TLD ROs. Please provide any input/suggestion for the draft outcome language on the mailing list by Friday, 8 July. Best Regards, Steve, Emily, Ariel
Dear Dennis, Thank you for providing the detailed input from RySG for Recommendation 2.6 and its rationale. Best Regards, Ariel From: "Tan Tanaka, Dennis" <dtantanaka@verisign.com> Date: Friday, August 19, 2022 at 4:36 PM To: Ariel Liang <ariel.liang@icann.org>, "gnso-epdp-idn-team@icann.org" <gnso-epdp-idn-team@icann.org> Subject: [Ext] Re: Confirm Edits: Group 2 Charter Questions Related to "Same Entity" Principle at Top-Level Ariel, et al Members of the RySG reviewed the proposed revision to the Rationale for Recommendation 2.6 which incorporates a reference to “usability goals for IDN variants”. We consider this addition to be inappropriate for two reasons. First, the language in the rationale should not be used to expand the intent (or scope) of the recommendation itself. In this case, Recommendation 2.6 refers to the technical and operational competence of a TLD registry operator, therefore the corresponding rationale should elaborate on the same terms. Second, the term “usability goals” is not defined which, if taken into consideration, can lead to subjective outcomes from an evaluation standpoint, which can impact predictability of the evaluation process. Therefore, the RySG respectfully rejects the latest revision to the language in the section Rationale for Recommendation 2.6. At the same time, we provide the following edits. Recommendation 2.6: The applicant will be required, as part of the application process, to explain the reason(s) why it needs to activate the applied-for variant label(s). In addition, the applicant will be required to demonstrate their ability to manage the primary IDN gTLD and the applied-for variant label(s) as a set from both a technical and operational perspective. Rationale for Recommendation 2.6: As IDN gTLDs and variant labels that are considered a set are yet to be delegated and operated at the root zone level, there is uncertainty about how athe set of variant TLDs will be managed and operated by athe registry operator from a technical and user perspective. Therefore, it will be important that applicants are able to explain their need for a set of IDN variant TLD label(s) as well as to demonstrate their technical capability to operate and manage the set of TLDs. Consequently Therefore, the applicant will be required to respond to additional application questions to address why they seek to activate those variant label(s) in addition to the primary new gTLD (i.e., necessity and expected usage of the variant labels), as well as how it plans to manage the set technically and operationally to achieve the security, stability, and usability goals for IDN variants as well as how it plans to manage the set operationally, with a view to ensuring a secure, stable, and consistent user experience. The applicant’s response to these questions is expected to be a critical component in the evaluation process. Evaluators with requisite expertise are expected to assess these responses. In addition, we ask the IDN EPDP working group to consider removing, or clarifying, the last two sentences (in green). They seem editorial in nature, and we are unsure as to what specifically these will accomplish. With respect to “The applicant’s response to these questions is expected to be a critical component in the evaluation process” Is the objective to promote IDN variant management competence questions over other aspects of the application? If the answer is no, then we don’t understand the need to make such an observation i.e., “critical component”. With respect to “Evaluators with requisite expertise are expected to assess these responses”, the RySG believes is a redundant and unnecessary statement as we expect that every step of the application process is undertaken in a professional and competent manner. However, if the intent is to provide instructions to the implementation team i.e., to seek ad hoc expertise, then we suggest making that clarification. The RySG does not have additional comments of the other remaining items. We are happy to continue this conversation over the course of the next working group meeting. Best, Dennis, on behalf the RySG IDN EPDP members From: Ariel Liang <ariel.liang@icann.org> Date: Friday, August 12, 2022 at 2:39 PM To: Dennis Tan Tanaka <dtantanaka@verisign.com>, "gnso-epdp-idn-team@icann.org" <gnso-epdp-idn-team@icann.org> Subject: [EXTERNAL] Confirm Edits: Group 2 Charter Questions Related to "Same Entity" Principle at Top-Level 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, During its meeting on 28 July [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1D9WAeo4A7tGzNRh7jMth-JcnjcXnvGtqYuUYgY8DQKQmJ1HbUZ_F78x5s15YF_HgVAPZVUrqGppq-hZQwU27_iTXQ6OxJv1W0U1OWB-_tEADI82dp0QnAgt_52TcfNUAGyQG-m5dQscTHTHJGmaY0Qz8ksvX4R4KooZJUY0ntNP1Z3frhRYqagYRm1k2demR_rGZlJYGlpxBGBvJhil7pTsf67Rn1eE9zaBS9Cwox92ljHliXcpWMEZRxSyGuT9K/https*3A*2F*2Fcommunity.icann.org*2Fx*2FJgYVD__;JSUlJSU!!PtGJab4!80S0xtwSy1vg0CRcDG-5EcUEZcykfCia7PDwAxDlgY0DlpmJZIcSNoUDOsfcCc1HjO4Ht2p3-ZcRw4ZFqs6ZMyAHEaYk$>, the EPDP Team discussed the input (mainly from RySG) for the outcome language of Group 2 charter questions. Members had preliminary agreement on the suggested edits discussed during the call. Since some members were not be able to make it to the 28 July call, staff are circulating the suggested edits for your review / confirmation. If no objection to the edits by EOB Friday, 19 August, we will regard these outcome languages stable. · Charter Question B2, Recommendation 2.3 and Rationale (p.2): https://docs.google.com/document/d/15YGISgNQYL_VfcVVZ6E97qbo42GPziP6x089bR3w... [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/15YGISgNQYL_VfcVVZ6E97qbo42GPziP6x089bR3wgZw/edit?usp=sharing__;!!PtGJab4!80S0xtwSy1vg0CRcDG-5EcUEZcykfCia7PDwAxDlgY0DlpmJZIcSNoUDOsfcCc1HjO4Ht2p3-ZcRw4ZFqs6ZM0VLcHwb$> · Charter Question D1b (Part 2), Rationale for Recommendation 2.5 and 2.6 (p.3): https://docs.google.com/document/d/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvUH... [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvUH5Sw/edit?usp=sharing__;!!PtGJab4!80S0xtwSy1vg0CRcDG-5EcUEZcykfCia7PDwAxDlgY0DlpmJZIcSNoUDOsfcCc1HjO4Ht2p3-ZcRw4ZFqs6ZM8MAscgh$> Thank you for your review! Best Regards, Ariel From: "Tan Tanaka, Dennis" <dtantanaka@verisign.com> Date: Friday, July 15, 2022 at 4:30 PM To: Ariel Liang <ariel.liang@icann.org>, "gnso-epdp-idn-team@icann.org" <gnso-epdp-idn-team@icann.org> Subject: [Ext] Re: [Gnso-epdp-idn-team] Reminder: Draft Outcome: Group 2 Charter Questions Related to "Same Entity" Principle at Top-Level Ariel, et al On behalf the RySG members of the EPDP I would like to submit the following observations to the draft outcomes. · Summary of the redline: Adding clarifying language to reflect that allocation alone of a TLD to a same entity cannot guarantee avoiding denial of service failure mode. · Proposed language: Rationale for Recommendation 2.1: To support its consideration of charter question B1, the EPDP Team reviewed the SubPro PDP recommendation 25.5 and Staff Paper recommendation 2, as well as their rationale. The EPDP Team agreed that abiding by the “same entity” principle and having the same registry operator for all allocatable variant labels of an existing gTLD will help minimize, but not guarantee, the security risk associated with the “failure modes” – including denial of service and misconnection – when dealing with variant labels. Therefore, the EPDP Team affirms to extend the SubPro PDP and the Staff Paper recommendations to existing gTLDs. · Why the redline? Recommendation 2.1 is applied at the top level, not at the domain name level. Making a TLD label allocatable to a single entity (or withheld) does not directly avoid the failure mode of denial of service. Even if the gTLD variant is activated into the root, an actual domain name (second level.variantTLD) needs to be registered and operated, in all variant TLDs. So, while it can help to minimize denial of service problem, it cannot guarantee it due to downstream actions (by other entities different than the registry operator) that need to be implemented. Therefore, the inclusion of a caveat. Related to this. For special purpose TLDs (brand, geo, community based) if the variant set is held to the same requirements, then it is possible that allocatable variants do not meet the same eligibility requirements as the primary label (for example, a trademark record). Avoiding denial of service due to an inactive TLD variant (in this case) is not only improbable, but impossible. · Summary of the redline: a registry operator should not be expected to ensure consistent user experience because it does not host or manage content (e.g. website, email services). · Rationale for Recommendation 2.6: As IDN gTLDs and variant labels that are considered a set are yet to be delegated and operated at the root zone level, there is uncertainty about how the set will be managed and operated by the registry operator from a technical and user perspective. Therefore, it will be important that applicants are able to explain their need for a set of IDN variant label(s) as well as demonstrate their technical capability to operate and manage the set. Therefore, the applicant will be required to respond to additional application questions to address why they seek to activate those variant label(s) in addition to the primary new gTLD (i.e., necessity and expected usage of the variant labels), as well as how it plans to manage the set operationally, with a view to ensuring a secure, stable, and consistent user experience. The applicant’s response to these questions is expected to be a critical component in the evaluation process. Evaluators with requisite expertise are expected to assess these responses. · Why the redline? While the language is in the rationale and not the draft recommendation, it may be misconstrued in an implementation guideline. We are far away from discussing operational requirements, but the suggestion that a registry operator should be expected to “manage” and “ensure” a “consistent user experience”, we think it may be misleading. We suggest removing that sentence from the rationale which does not affect the overall intent. · Summary of the redline: Minor change for consistency in terminology. · Recommendation 2.3: If the registry operator operating a variant gTLD label changes its back-end registry service provider, all the variant gTLD label(s) in the set must also switch transition to the same new back-end registry service provider. · Why the redline? Harmonizing language with MSA change process [secure-web.cisco.com] [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1Bro8B5l_Wcw-ezqU1OiQcoObazPmJzwJpUWFjkiiXES00JXqtKgI2gVz_hD2sXstZm5_ldcDUgHHJswFa4JQxfOuyTD-tSJEf1mpWyvxHalSD72s_pziLy4RZD7Wg88_f75QkdAD03V8ed99QB1107S1_mMhQ_0M56lWRu5kxWY-xuXzCpiJ_54AdTbxgTZioJy1VY2tTqedXvux8cLXGwLD65rJDWvGiQenDHZHF9712hdTfQjq8aQTGC4tNRx2/https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fsecure-web.cisco.com*2F17PTWZSoYgDuVsWnubBEirA3cdXcqCb3xaJvHUco0vIFE1JznqamjdBb352P4KjBxpAuek6hCj41p3O8PuxP9PM79-0BPFb5L7RGgGbfTTiXelonTZdunNe_W5PB0ASOjWhihZyP_riulkqkwG0aSheBh8C8EL5ZSdHLHoL9M-PsZBj9LUbBvCzKQOsdRqirobmmtSBBiaNZBcSJLwJhuMtIIonNwaAL1cJi1dslnQIbkg1YPz3Exx0LsSGSN5CUQ*2Fhttps*2A3A*2A2F*2A2Fwww.icann.org*2A2Fresources*2A2Fmaterial-subcontracting-arrangement__*3BJSUlJSU*21*21PtGJab4*218c3Wua0ZIsCJQHOFJY_Hi171n9LVSKFXACciHXiBvFTWzNf8ZwMMPgLO40g-0oKSqBsyaCSdL8dpYhShiwllm2lE0Osb*24__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!PtGJab4!80S0xtwSy1vg0CRcDG-5EcUEZcykfCia7PDwAxDlgY0DlpmJZIcSNoUDOsfcCc1HjO4Ht2p3-ZcRw4ZFqs6ZM-6XYiBo$>, which uses the term “transition”. One additional note. On draft recommendation 2.8 (B5: special purpose TLDs) I have shared the draft outcome with our colleagues in the Brand Registry Group and GeoTLD Group. I’m working with them to get their insights, so I’d like to ask for your patience while I compile their input. Thank you, Dennis, on behalf the RySG IDN EPDP members From: Gnso-epdp-idn-team <gnso-epdp-idn-team-bounces@icann.org> on behalf of Ariel Liang <ariel.liang@icann.org> Date: Thursday, July 14, 2022 at 12:04 PM To: "gnso-epdp-idn-team@icann.org" <gnso-epdp-idn-team@icann.org> Subject: [EXTERNAL] [Gnso-epdp-idn-team] Reminder: Draft Outcome: Group 2 Charter Questions Related to "Same Entity" Principle at Top-Level 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, This is the final reminder for reviewing the draft outcome language for Group 2 charter questions by EOB Friday, 15 July (initial deadline extended by one week). Please see details below. FYI - the ALAC Team informed staff that they agree with the draft language for those questions. Best Regards, Ariel From: Ariel Liang <ariel.liang@icann.org> Date: Friday, June 24, 2022 at 11:43 AM To: "gnso-epdp-idn-team@icann.org" <gnso-epdp-idn-team@icann.org> Subject: Draft Outcome: Group 2 Charter Questions Related to "Same Entity" Principle at Top-Level Dear All Please find the draft outcome language for Group 2 charter questions related to “same entity” principle at the top-level, which are: · B1, B2, B3, B5: https://docs.google.com/document/d/15YGISgNQYL_VfcVVZ6E97qbo42GPziP6x089bR3w... [docs.google.com] [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/125QVY2mWi6jyMF5qSWVo_aIiWbivCcQNGcDg4vsmBBg2a2Q4t3nk_roJIxw6Mgkq_S0Hk96rftyP4vM6UKMz-OpaULPw4A0rFL2Hm4Z0lvuKNAhNBWbxJGNWe_3CWaOAh2wOAsnUbFr06Yf79h62LQMN64T-fdQBjhgjUBXXGWVRAyqBMVKek_iHFtNTicyAhGB2RUjdtlSYXrtlJ1y9kFLUphxmC53IHAT8KKnTxWiEmMeGD0VFs7jmJg_HyRqA/https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fdocs.google.com*2Fdocument*2Fd*2F15YGISgNQYL_VfcVVZ6E97qbo42GPziP6x089bR3wgZw*2Fedit*3Fusp*3Dsharing__*3B*21*21PtGJab4*218c3Wua0ZIsCJQHOFJY_Hi171n9LVSKFXACciHXiBvFTWzNf8ZwMMPgLO40g-0oKSqBsyaCSdL8dpYhShiwllm-8sFIOs*24__;JSUlJSUlJSUlJSUlJSUlJSUl!!PtGJab4!80S0xtwSy1vg0CRcDG-5EcUEZcykfCia7PDwAxDlgY0DlpmJZIcSNoUDOsfcCc1HjO4Ht2p3-ZcRw4ZFqs6ZM3Mf4-mP$> · D1a, D1b (Part 2): https://docs.google.com/document/d/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvUH... [docs.google.com] [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1subCSwwrqimEMVMn-UKhDQDtVB11pJDsEcTHLRPJmt3aieu0smxUoi5hMHj_oIdL1WYBC3fELaFhNaggiYVrz9G8_3Dbk1w6ozBYU4gdeIxEOCqQG3skpynDBM6o743OJ3ja8j-WAz-_fhkyzbeRXZf46O_Zdr1Y-FzMOup_cBiW6h5RkBN4g0bfrPpd-85JonoGmK8N9u4QEv3krSioU_n5fDJ2u8GtnpdFCm-1eJ4T4-jwjauSYjv3ZXtte9V_/https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fdocs.google.com*2Fdocument*2Fd*2F1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvUH5Sw*2Fedit*3Fusp*3Dsharing__*3B*21*21PtGJab4*218c3Wua0ZIsCJQHOFJY_Hi171n9LVSKFXACciHXiBvFTWzNf8ZwMMPgLO40g-0oKSqBsyaCSdL8dpYhShiwllmxcb5Nox*24__;JSUlJSUlJSUlJSUlJSUlJSUl!!PtGJab4!80S0xtwSy1vg0CRcDG-5EcUEZcykfCia7PDwAxDlgY0DlpmJZIcSNoUDOsfcCc1HjO4Ht2p3-ZcRw4ZFqs6ZM-WSbxFF$> Both documents are also posted on the wiki page here: https://community.icann.org/x/XwyHCg [secure-web.cisco.com] [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/12gAmWA9f-L3J1E-FfuWRHTwT1Awve1kIy7v1ecTEtezNzHKAw1BtRq08Xn9VA8ySVOCjyG-I5Rs8rI3KOqOdfBaN2UeXuEM31JO_Jb7tpj9NPyJwTk8Up77JMjIIfhRXr_mrQkDq1plktIOk8aSsox6vAy98ItRJ6tr6Y6S8xLlnrS6ucjAXk4leLF1I3AMrH4ZLpi86vrEBlLi84z1Yd8GUP3sWjGvuMrIV-rpY-L7Yweu2BqTw19H5UWshaoZF/https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fsecure-web.cisco.com*2F1cLkZefuhXu_uH3vPKV-WqdDsF3bAzHFSuVy6oxj5LpOcybpNP4PyqXxwdzXfKE839qWUKiXL4Tac845XODFW9zsz-2JTwMygfJszPmKDuLAJup98RKhMiPeOff-kGqgdD4cKTDFD7L0B-9HvQoE_fGIjrTbxPFuTcTETGelO62_PEs9hq2SqTx0oyTv21YDmCba0hl6L1fsggbDua02iAwynycwUCw8SQ3boexaJTHDEqxtRlrTNkmGmyoakpGkF*2Fhttps*2A3A*2A2F*2A2Fcommunity.icann.org*2A2Fx*2A2FXwyHCg__*3BJSUlJSU*21*21PtGJab4*218c3Wua0ZIsCJQHOFJY_Hi171n9LVSKFXACciHXiBvFTWzNf8ZwMMPgLO40g-0oKSqBsyaCSdL8dpYhShiwllmxDegkHS*24__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!PtGJab4!80S0xtwSy1vg0CRcDG-5EcUEZcykfCia7PDwAxDlgY0DlpmJZIcSNoUDOsfcCc1HjO4Ht2p3-ZcRw4ZFqs6ZMwjEzpC6$>. Following the agreed format, the draft outcome language includes the following components: · Brief answer to the charter question · Recommendations and implementation guidance · Rationale for recommendations and implementation guidance Please note that for charter question D1b Part 1 (related to the process by which an existing TLD registry operator seeks to activate variants) has not be addressed; it depends on the survey responses from the Arabic/Chinese TLD ROs. Please provide any input/suggestion for the draft outcome language on the mailing list by Friday, 8 July. Best Regards, Steve, Emily, Ariel
Dear all The ALAC team respectfully puts forward the following points in response to the inputs from RySG made earlier: 1. At the outset, we recognize the fact that IDN Variants have been proposed in response to the needs of language communities and end-users, where the use of variant labels is usual and expected. 2. As we are in the process of introducing variant labels and label sets for the first time, we note that there is a high likelihood of differences between the current operational practices and the practices after we introduce variant labels and sets. 3. It is important to ensure that the end-user aspects of socializing such differences are considered by the EPDP on IDNs. 4. We would consider the consistency of user experience as an integral part of the “operational aspects” when we introduce variant labels and sets on the root zone. Part of the difficulty is that “operational aspects” are not defined, and are perhaps implicitly assumed to be based on the current practices at the levels of RO-Registrar-Reseller. When considering variant labels and sets, we propose that the impact on end-users (both registrants and users of domain names) be also explicitly considered under the rubric of “operational aspects”, in which case the consistency of end-user experience *vis-à-vis* variants becomes important to consider. 5. We are flexible regarding the use of the phrase “usability goals”, but we would recommend ensuring that the consistency of end-user experience is captured in the Rationale for Recommendation 2.6. With kind regards satish On Tue, Aug 23, 2022 at 6:46 AM Ariel Liang <ariel.liang@icann.org> wrote:
Dear Dennis,
Thank you for providing the detailed input from RySG for Recommendation 2.6 and its rationale.
Best Regards,
Ariel
*From: *"Tan Tanaka, Dennis" <dtantanaka@verisign.com> *Date: *Friday, August 19, 2022 at 4:36 PM *To: *Ariel Liang <ariel.liang@icann.org>, "gnso-epdp-idn-team@icann.org" <gnso-epdp-idn-team@icann.org> *Subject: *[Ext] Re: Confirm Edits: Group 2 Charter Questions Related to "Same Entity" Principle at Top-Level
Ariel, et al
Members of the RySG reviewed the proposed revision to the Rationale for Recommendation 2.6 which incorporates a reference to “usability goals for IDN variants”. We consider this addition to be inappropriate for two reasons. First, the language in the rationale should not be used to expand the intent (or scope) of the recommendation itself. In this case, Recommendation 2.6 refers to the technical and operational competence of a TLD registry operator, therefore the corresponding rationale should elaborate on the same terms. Second, the term “usability goals” is not defined which, if taken into consideration, can lead to subjective outcomes from an evaluation standpoint, which can impact predictability of the evaluation process.
Therefore, the RySG respectfully rejects the latest revision to the language in the section Rationale for Recommendation 2.6. At the same time, we provide the following edits.
*Recommendation 2.6:* The applicant will be required, as part of the application process, to explain the reason(s) why it needs to activate the applied-for variant label(s). In addition, the applicant will be required to demonstrate their ability to manage the primary IDN gTLD and the applied-for variant label(s) as a set from both a technical and operational perspective.
*Rationale for Recommendation 2.6*: As IDN gTLDs and variant labels that are considered a set are yet to be delegated and operated at the root zone level, there is uncertainty about how athe set of variant TLDs will be managed and operated by athe registry operator from a technical and user perspective. Therefore, it will be important that applicants are able to explain their need for a set of IDN variant TLD label(s) as well as to demonstrate their technical capability to operate and manage the set of TLDs. Consequently Therefore, the applicant will be required to respond to additional application questions to address why they seek to activate those variant label(s) in addition to the primary new gTLD (i.e., necessity and expected usage of the variant labels), as well as how it plans to manage the set technically and operationally to achieve the security, stability, and usability goals for IDN variants as well as how it plans to manage the set operationally, with a view to ensuring a secure, stable, and consistent user experience. The applicant’s response to these questions is expected to be a critical component in the evaluation process. Evaluators with requisite expertise are expected to assess these responses.
In addition, we ask the IDN EPDP working group to consider removing, or clarifying, the last two sentences (in green). They seem editorial in nature, and we are unsure as to what specifically these will accomplish. With respect to *“The applicant’s response to these questions is expected to be a critical component in the evaluation process*” Is the objective to promote IDN variant management competence questions over other aspects of the application? If the answer is no, then we don’t understand the need to make such an observation i.e., *“critical component”.* With respect to *“Evaluators with requisite expertise are expected to assess these responses”, *the RySG believes is a redundant and unnecessary statement as we expect that every step of the application process is undertaken in a professional and competent manner. However, if the intent is to provide instructions to the implementation team i.e., to seek ad hoc expertise, then we suggest making that clarification.
The RySG does not have additional comments of the other remaining items.
We are happy to continue this conversation over the course of the next working group meeting.
Best,
Dennis, on behalf the RySG IDN EPDP members
*From: *Ariel Liang <ariel.liang@icann.org> *Date: *Friday, August 12, 2022 at 2:39 PM *To: *Dennis Tan Tanaka <dtantanaka@verisign.com>, " gnso-epdp-idn-team@icann.org" <gnso-epdp-idn-team@icann.org> *Subject: *[EXTERNAL] Confirm Edits: Group 2 Charter Questions Related to "Same Entity" Principle at Top-Level
*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,
During its meeting on 28 July [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1D9WAeo4A7tGzNRh7jMth-JcnjcXnvGtqYuUYgY8DQKQmJ1HbUZ_F78x5s15YF_HgVAPZVUrqGppq-hZQwU27_iTXQ6OxJv1W0U1OWB-_tEADI82dp0QnAgt_52TcfNUAGyQG-m5dQscTHTHJGmaY0Qz8ksvX4R4KooZJUY0ntNP1Z3frhRYqagYRm1k2demR_rGZlJYGlpxBGBvJhil7pTsf67Rn1eE9zaBS9Cwox92ljHliXcpWMEZRxSyGuT9K/https*3A*2F*2Fcommunity.icann.org*2Fx*2FJgYVD__;JSUlJSU!!PtGJab4!80S0xtwSy1vg0CRcDG-5EcUEZcykfCia7PDwAxDlgY0DlpmJZIcSNoUDOsfcCc1HjO4Ht2p3-ZcRw4ZFqs6ZMyAHEaYk$>, the EPDP Team discussed the input (mainly from RySG) for the outcome language of Group 2 charter questions. Members had preliminary agreement on the suggested edits discussed during the call.
Since some members were not be able to make it to the 28 July call, staff are circulating the suggested edits for your review / confirmation. If no objection to the edits by *EOB Friday, 19 August*, we will regard these outcome languages stable.
· Charter Question B2, Recommendation 2.3 and Rationale (p.2): https://docs.google.com/document/d/15YGISgNQYL_VfcVVZ6E97qbo42GPziP6x089bR3w... [docs.google.com] <https://urldefense.com/v3/__https:/docs.google.com/document/d/15YGISgNQYL_VfcVVZ6E97qbo42GPziP6x089bR3wgZw/edit?usp=sharing__;!!PtGJab4!80S0xtwSy1vg0CRcDG-5EcUEZcykfCia7PDwAxDlgY0DlpmJZIcSNoUDOsfcCc1HjO4Ht2p3-ZcRw4ZFqs6ZM0VLcHwb$>
· Charter Question D1b (Part 2), Rationale for Recommendation 2.5 and 2.6 (p.3): https://docs.google.com/document/d/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvUH... [docs.google.com] <https://urldefense.com/v3/__https:/docs.google.com/document/d/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvUH5Sw/edit?usp=sharing__;!!PtGJab4!80S0xtwSy1vg0CRcDG-5EcUEZcykfCia7PDwAxDlgY0DlpmJZIcSNoUDOsfcCc1HjO4Ht2p3-ZcRw4ZFqs6ZM8MAscgh$>
Thank you for your review!
Best Regards,
Ariel
*From: *"Tan Tanaka, Dennis" <dtantanaka@verisign.com> *Date: *Friday, July 15, 2022 at 4:30 PM *To: *Ariel Liang <ariel.liang@icann.org>, "gnso-epdp-idn-team@icann.org" <gnso-epdp-idn-team@icann.org> *Subject: *[Ext] Re: [Gnso-epdp-idn-team] Reminder: Draft Outcome: Group 2 Charter Questions Related to "Same Entity" Principle at Top-Level
Ariel, et al
On behalf the RySG members of the EPDP I would like to submit the following observations to the draft outcomes.
· *Summary of the redline*: Adding clarifying language to reflect that allocation alone of a TLD to a same entity cannot guarantee avoiding denial of service failure mode.
· *Proposed language: Rationale for Recommendation 2.1*: To support its consideration of charter question B1, the EPDP Team reviewed the SubPro PDP recommendation 25.5 and Staff Paper recommendation 2, as well as their rationale. The EPDP Team agreed that abiding by the “same entity” principle and having the same registry operator for all allocatable variant labels of an existing gTLD will help minimize, but not guarantee, the security risk associated with the “failure modes” – including denial of service and misconnection – when dealing with variant labels. Therefore, the EPDP Team affirms to extend the SubPro PDP and the Staff Paper recommendations to existing gTLDs.
· *Why the redline?* Recommendation 2.1 is applied at the top level, not at the domain name level. Making a TLD label allocatable to a single entity (or withheld) does not directly avoid the failure mode of denial of service. Even if the gTLD variant is activated into the root, an actual domain name (second level.variantTLD) needs to be registered and operated, in all variant TLDs. So, while it can help to minimize denial of service problem, it cannot guarantee it due to downstream actions (by other entities different than the registry operator) that need to be implemented. Therefore, the inclusion of a caveat. Related to this. For special purpose TLDs (brand, geo, community based) if the variant set is held to the same requirements, then it is possible that allocatable variants do not meet the same eligibility requirements as the primary label (for example, a trademark record). Avoiding denial of service due to an inactive TLD variant (in this case) is not only improbable, but impossible.
· *Summary of the redline*: a registry operator should not be expected to ensure consistent user experience because it does not host or manage content (e.g. website, email services).
· *Rationale for Recommendation 2.6*: As IDN gTLDs and variant labels that are considered a set are yet to be delegated and operated at the root zone level, there is uncertainty about how the set will be managed and operated by the registry operator from a technical and user perspective. Therefore, it will be important that applicants are able to explain their need for a set of IDN variant label(s) as well as demonstrate their technical capability to operate and manage the set. Therefore, the applicant will be required to respond to additional application questions to address why they seek to activate those variant label(s) in addition to the primary new gTLD (i.e., necessity and expected usage of the variant labels), as well as how it plans to manage the set operationally, with a view to ensuring a secure, stable, and consistent user experience. The applicant’s response to these questions is expected to be a critical component in the evaluation process. Evaluators with requisite expertise are expected to assess these responses.
· *Why the redline*? While the language is in the rationale and not the draft recommendation, it may be misconstrued in an implementation guideline. We are far away from discussing operational requirements, but the suggestion that a registry operator should be expected to “manage” and “ensure” a “consistent user experience”, we think it may be misleading. We suggest removing that sentence from the rationale which does not affect the overall intent.
· *Summary of the redline*: Minor change for consistency in terminology.
· *Recommendation 2.3*: If the registry operator operating a variant gTLD label changes its back-end registry service provider, all the variant gTLD label(s) in the set must also switch transition to the same new back-end registry service provider.
· *Why the redline?* Harmonizing language with MSA change process [secure-web.cisco.com] [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1Bro8B5l_Wcw-ezqU1OiQcoObazPmJzwJpUWFjkiiXES00JXqtKgI2gVz_hD2sXstZm5_ldcDUgHHJswFa4JQxfOuyTD-tSJEf1mpWyvxHalSD72s_pziLy4RZD7Wg88_f75QkdAD03V8ed99QB1107S1_mMhQ_0M56lWRu5kxWY-xuXzCpiJ_54AdTbxgTZioJy1VY2tTqedXvux8cLXGwLD65rJDWvGiQenDHZHF9712hdTfQjq8aQTGC4tNRx2/https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fsecure-web.cisco.com*2F17PTWZSoYgDuVsWnubBEirA3cdXcqCb3xaJvHUco0vIFE1JznqamjdBb352P4KjBxpAuek6hCj41p3O8PuxP9PM79-0BPFb5L7RGgGbfTTiXelonTZdunNe_W5PB0ASOjWhihZyP_riulkqkwG0aSheBh8C8EL5ZSdHLHoL9M-PsZBj9LUbBvCzKQOsdRqirobmmtSBBiaNZBcSJLwJhuMtIIonNwaAL1cJi1dslnQIbkg1YPz3Exx0LsSGSN5CUQ*2Fhttps*2A3A*2A2F*2A2Fwww.icann.org*2A2Fresources*2A2Fmaterial-subcontracting-arrangement__*3BJSUlJSU*21*21PtGJab4*218c3Wua0ZIsCJQHOFJY_Hi171n9LVSKFXACciHXiBvFTWzNf8ZwMMPgLO40g-0oKSqBsyaCSdL8dpYhShiwllm2lE0Osb*24__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!PtGJab4!80S0xtwSy1vg0CRcDG-5EcUEZcykfCia7PDwAxDlgY0DlpmJZIcSNoUDOsfcCc1HjO4Ht2p3-ZcRw4ZFqs6ZM-6XYiBo$>, which uses the term “transition”.
One additional note. On draft recommendation 2.8 (B5: special purpose TLDs) I have shared the draft outcome with our colleagues in the Brand Registry Group and GeoTLD Group. I’m working with them to get their insights, so I’d like to ask for your patience while I compile their input.
Thank you,
Dennis, on behalf the RySG IDN EPDP members
*From: *Gnso-epdp-idn-team <gnso-epdp-idn-team-bounces@icann.org> on behalf of Ariel Liang <ariel.liang@icann.org> *Date: *Thursday, July 14, 2022 at 12:04 PM *To: *"gnso-epdp-idn-team@icann.org" <gnso-epdp-idn-team@icann.org> *Subject: *[EXTERNAL] [Gnso-epdp-idn-team] Reminder: Draft Outcome: Group 2 Charter Questions Related to "Same Entity" Principle at Top-Level
*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,
This is the final reminder for reviewing the draft outcome language for Group 2 charter questions by *EOB Friday, 15 July* (initial deadline extended by one week). Please see details below.
FYI - the ALAC Team informed staff that they agree with the draft language for those questions.
Best Regards,
Ariel
*From: *Ariel Liang <ariel.liang@icann.org> *Date: *Friday, June 24, 2022 at 11:43 AM *To: *"gnso-epdp-idn-team@icann.org" <gnso-epdp-idn-team@icann.org> *Subject: *Draft Outcome: Group 2 Charter Questions Related to "Same Entity" Principle at Top-Level
Dear All
Please find the draft outcome language for Group 2 charter questions related to “same entity” principle at the top-level, which are:
· B1, B2, B3, B5: https://docs.google.com/document/d/15YGISgNQYL_VfcVVZ6E97qbo42GPziP6x089bR3w... [docs.google.com] [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/125QVY2mWi6jyMF5qSWVo_aIiWbivCcQNGcDg4vsmBBg2a2Q4t3nk_roJIxw6Mgkq_S0Hk96rftyP4vM6UKMz-OpaULPw4A0rFL2Hm4Z0lvuKNAhNBWbxJGNWe_3CWaOAh2wOAsnUbFr06Yf79h62LQMN64T-fdQBjhgjUBXXGWVRAyqBMVKek_iHFtNTicyAhGB2RUjdtlSYXrtlJ1y9kFLUphxmC53IHAT8KKnTxWiEmMeGD0VFs7jmJg_HyRqA/https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fdocs.google.com*2Fdocument*2Fd*2F15YGISgNQYL_VfcVVZ6E97qbo42GPziP6x089bR3wgZw*2Fedit*3Fusp*3Dsharing__*3B*21*21PtGJab4*218c3Wua0ZIsCJQHOFJY_Hi171n9LVSKFXACciHXiBvFTWzNf8ZwMMPgLO40g-0oKSqBsyaCSdL8dpYhShiwllm-8sFIOs*24__;JSUlJSUlJSUlJSUlJSUlJSUl!!PtGJab4!80S0xtwSy1vg0CRcDG-5EcUEZcykfCia7PDwAxDlgY0DlpmJZIcSNoUDOsfcCc1HjO4Ht2p3-ZcRw4ZFqs6ZM3Mf4-mP$>
· D1a, D1b (Part 2): https://docs.google.com/document/d/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvUH... [docs.google.com] [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1subCSwwrqimEMVMn-UKhDQDtVB11pJDsEcTHLRPJmt3aieu0smxUoi5hMHj_oIdL1WYBC3fELaFhNaggiYVrz9G8_3Dbk1w6ozBYU4gdeIxEOCqQG3skpynDBM6o743OJ3ja8j-WAz-_fhkyzbeRXZf46O_Zdr1Y-FzMOup_cBiW6h5RkBN4g0bfrPpd-85JonoGmK8N9u4QEv3krSioU_n5fDJ2u8GtnpdFCm-1eJ4T4-jwjauSYjv3ZXtte9V_/https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fdocs.google.com*2Fdocument*2Fd*2F1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvUH5Sw*2Fedit*3Fusp*3Dsharing__*3B*21*21PtGJab4*218c3Wua0ZIsCJQHOFJY_Hi171n9LVSKFXACciHXiBvFTWzNf8ZwMMPgLO40g-0oKSqBsyaCSdL8dpYhShiwllmxcb5Nox*24__;JSUlJSUlJSUlJSUlJSUlJSUl!!PtGJab4!80S0xtwSy1vg0CRcDG-5EcUEZcykfCia7PDwAxDlgY0DlpmJZIcSNoUDOsfcCc1HjO4Ht2p3-ZcRw4ZFqs6ZM-WSbxFF$>
Both documents are also posted on the wiki page here: https://community.icann.org/x/XwyHCg [secure-web.cisco.com] [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/12gAmWA9f-L3J1E-FfuWRHTwT1Awve1kIy7v1ecTEtezNzHKAw1BtRq08Xn9VA8ySVOCjyG-I5Rs8rI3KOqOdfBaN2UeXuEM31JO_Jb7tpj9NPyJwTk8Up77JMjIIfhRXr_mrQkDq1plktIOk8aSsox6vAy98ItRJ6tr6Y6S8xLlnrS6ucjAXk4leLF1I3AMrH4ZLpi86vrEBlLi84z1Yd8GUP3sWjGvuMrIV-rpY-L7Yweu2BqTw19H5UWshaoZF/https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fsecure-web.cisco.com*2F1cLkZefuhXu_uH3vPKV-WqdDsF3bAzHFSuVy6oxj5LpOcybpNP4PyqXxwdzXfKE839qWUKiXL4Tac845XODFW9zsz-2JTwMygfJszPmKDuLAJup98RKhMiPeOff-kGqgdD4cKTDFD7L0B-9HvQoE_fGIjrTbxPFuTcTETGelO62_PEs9hq2SqTx0oyTv21YDmCba0hl6L1fsggbDua02iAwynycwUCw8SQ3boexaJTHDEqxtRlrTNkmGmyoakpGkF*2Fhttps*2A3A*2A2F*2A2Fcommunity.icann.org*2A2Fx*2A2FXwyHCg__*3BJSUlJSU*21*21PtGJab4*218c3Wua0ZIsCJQHOFJY_Hi171n9LVSKFXACciHXiBvFTWzNf8ZwMMPgLO40g-0oKSqBsyaCSdL8dpYhShiwllmxDegkHS*24__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!PtGJab4!80S0xtwSy1vg0CRcDG-5EcUEZcykfCia7PDwAxDlgY0DlpmJZIcSNoUDOsfcCc1HjO4Ht2p3-ZcRw4ZFqs6ZMwjEzpC6$>.
Following the agreed format, the draft outcome language includes the following components:
· Brief answer to the charter question
· Recommendations and implementation guidance
· Rationale for recommendations and implementation guidance
Please note that for charter question D1b Part 1 (related to the process by which an existing TLD registry operator seeks to activate variants) has not be addressed; it depends on the survey responses from the Arabic/Chinese TLD ROs.
Please provide any input/suggestion for the draft outcome language on the *mailing list* by *Friday,** 8 July*.
Best Regards,
Steve, Emily, Ariel
_______________________________________________ Gnso-epdp-idn-team mailing list Gnso-epdp-idn-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-idn-team
participants (3)
-
Ariel Liang -
Satish Babu -
Tan Tanaka, Dennis