[Gnso-epdp-idn-team] [Ext] Re: Confirm Edits: Group 2 Charter Questions Related to "Same Entity" Principle at Top-Level

Satish Babu sbabu at ieee.org
Tue Aug 30 05:28:23 UTC 2022 

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 at 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 at verisign.com>
> *Date: *Friday, August 19, 2022 at 4:36 PM
> *To: *Ariel Liang <ariel.liang at icann.org>, "gnso-epdp-idn-team at icann.org"
> <gnso-epdp-idn-team at 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 at icann.org>
> *Date: *Friday, August 12, 2022 at 2:39 PM
> *To: *Dennis Tan Tanaka <dtantanaka at verisign.com>, "
> gnso-epdp-idn-team at icann.org" <gnso-epdp-idn-team at 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_VfcVVZ6E97qbo42GPziP6x089bR3wgZw/edit?usp=sharing
> [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/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvUH5Sw/edit?usp=sharing
> [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 at verisign.com>
> *Date: *Friday, July 15, 2022 at 4:30 PM
> *To: *Ariel Liang <ariel.liang at icann.org>, "gnso-epdp-idn-team at icann.org"
> <gnso-epdp-idn-team at 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 at icann.org> on
> behalf of Ariel Liang <ariel.liang at icann.org>
> *Date: *Thursday, July 14, 2022 at 12:04 PM
> *To: *"gnso-epdp-idn-team at icann.org" <gnso-epdp-idn-team at 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 at icann.org>
> *Date: *Friday, June 24, 2022 at 11:43 AM
> *To: *"gnso-epdp-idn-team at icann.org" <gnso-epdp-idn-team at 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_VfcVVZ6E97qbo42GPziP6x089bR3wgZw/edit?usp=sharing
> [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/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvUH5Sw/edit?usp=sharing
> [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 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/20220830/f82086cf/attachment-0001.html>

More information about the Gnso-epdp-idn-team mailing list