[Gnso-epdp-idn-team] Notes and Action Items - IDNs EPDP Meeting #94 - 31 August 2923
Daniel Gluck
daniel.gluck at icann.org
Fri Sep 1 21:32:50 UTC 2023
Hi All,
Please find below the notes and action items from the 31 August 2023 IDNs EPDP meeting #94<https://community.icann.org/x/yoyZDg> at 12:00 UTC.
Best regards,
Ariel, Steve, and Dan
ACTION ITEMS
* Leadership will look to set an agenda for the F2F in October as to allow representative groups time to discuss and strategize for the meeting
* Leadership will reconsider Recommendation 3.xx for further clarification
* Leadership will work to re-write Rec. 3.5.4. to better address the responsibilities of the registry operator in relation to the end-user.
* Leadership will discuss the wording of 3.5.1 and determine if the second part of the statement is redundant due to the definition of variant.
* The ALAC will review the updated language in Rec 3.5 and IG 3.6
* The team will deliberate on IG 3.9 and how to proceed with the specifics of the application process
NOTES
* Roll Call and SOI Updates
* Welcome and Chair Updates
* The chair welcomed everyone to the call
* Updates were provided on the upcoming Face to Face Workshop (F2F)
* The dates will be between 6 December to 8 December
* Details were provided for Travel Support for those who meet the requirements to receive funding
* Most of the content for this meeting will be focused on Phase 2 of the EPDP
* ACTION ITEM: Leadership will look to set an agenda for the F2F in October as to allow representative groups time to discuss and strategize for the meeting
* Review of Proposed Updates of Phase 1 Final Recommendations
* The Chair provided a background for the Final Recommendations for Phase 1 of the EPDP
* Staff then provided more detailed information and walked the team through the document
* Redline was used to denote changes from the initial report
* Rec 1.1 contains a minor verbiage change and the rationale was also updated
* This received unanimous support from the team.
* Rec 2.1 contains changes to avoid being repetitive in the text and future-proofed (removed “IDN”) and updates to the rationale to expand on the removal of the asterisk
* This update is part of the global change for futureproofing
* There was a question from a team member regarding the grammar of “only” to refer to a specific registry operator, which was discussed by Leadership
* This was deliberately included and meant to emphasize the point and was agreed to by the team member
* This recommendation was agreed to by the team
* Rec 3.1 contains the global change and Rec 3.2 changes “delegated” to “existing” for clarity, including rationale for the decisions
* This was agreed to by the team
* Rec 3.3 contains similar edits for the future-proofing global change
* There was a discussion from the team over possibly removing reference to the 2012 round, but this was not needed due to the differentiation between TLD and SLD
* The recommendation was agreed to by the team
* Rec 3.4 received a slightly more detailed change due to verbiage being updated to comply with comments received
* This was approved by the team as it addresses ICANN Org’s concerns about the original wording
* This recommendation was agreed to by the team
* Rec 3.xx is a new recommendation from leadership to capture a request for clarification on Rec 3.4 and clarifies that there are no swapping of variant labels with the exception of Brand TLD variant labels due to the existing recommendation from SubPro which explicitly states this
* A member of team requested more clarification to be made in the wording
* ACTION ITEM: Leadership will reconsider Recommendation 3.xx for further clarification
* A team member asked if there would be future public comment due to the new recommendations, but the chair explained there would not be. The venue for stakeholder comment is through the team members of the EPDP. There will be an opportunity for the team to provide their thoughts on the updates at a future meeting
* Rec 3.5 contains revised and additional language for the explanation of the mission and purpose of the primary gTLD string from applicants
* This received a comment from a team member in the document regarding clarity of a specific wording choice and this rolled up into discussion of I.G 3.6
* I.G. 3.6 is written in support of the goal to prevent frivolous applications for allocatable variant labels
* There was discussion on the team of the value of a scoring system against just having pass/fail
* The chair described a scenario where there could be overall scores for the entirety of a gTLD registration or just the IDN part of the registration. The implementation guidance should allow evaluators to make that distinction if that is how the SubPro implementation guidance gets delivered
* A team member asked what type of information the registry would have to provide for 3.5.4 that would satisfy the evaluators.
* The nuance, said the team member, is in the relationship between the end user and the registrant. The team member proposed potentially rewriting this part of the recommendation as it will be difficult for the registry operator to enforce policies with all the intermediaries between the end-user and the registry operator (registrar, resellers, etc.). They would prefer the language be tightened up to become answerable by the registry operator
* This was agreed to by the chair
* ACTION ITEM: Leadership will work to re-write Rec. 3.5.4. to better address the responsibilities of the registry operator in relation to the end-user.
* A comment on 3.5.1 asked about potentially confusing language
* The second part of 3.5.1 may be redundant due to the word “meaning”. The variant should already be equivalent to the primary string, per the team member, and therefore may be able to be shortened and merged with 3.5.2.
* ACTION ITEM: Leadership will discuss the wording of 3.5.1 and determine if the second part of the statement is redundant due to the definition of variant.
* Another participant in the chat wrote: “My quick comment focuses on ‘how it is the same as the applied-for primary gTLD string or existing gTLD’. The meaning of the primary gTLD is de facto the same with that of its variants. They are only different in written form but have the same meaning. So, applicants do not need to answer this question.”
* Leadership followed up to ask if this is the case with scripts other than Chinese.
* There was also a comment about the subjective nature of the language and criteria in 3.5.3 and 3.5.4
* A comment suggested 3.5.4 may not be needed due to the same-entity principle
* This is in light of the registry operator or registrar not having much control over who is going to register a name at a second level. Unless the list of strings registered at the second level are predetermined, it would be impossible to regulate this.
* The Chair asked if the team believes 3.5.4 is necessary to be included.
* Another comment suggested that much of the application process is subjective and potentially challenging for the evaluators
* A comment from staff mentioned “much of the new gTLD program is based on subjective criteria so in that sense, this is not a new problem. The evaluators need to be able come up with consistent results, even in cases where there are multiple firms performing the evaluation. And for context, the SubPro PDP made Rec 27.2 (“Evaluation scores on all questions should be limited to a pass/fail
* scale (0-1 points only)” to not only simplify the process, but to also reduce the level of subjectivity in evaluation.”
* There was a discussion on the “general standard of reasonableness” and the consistency from evaluators
* One participant in chat summed up their thoughts by posing the question of “how to [ensure] that evaluators use the same rule to measure all applications”
* They then followed up with “I think we cannot evaluate these detailed questions/requests for information without knowing how it will be evaluated. As the example I used, if the applicant fills out an answer, would that be considered a PASS? Or are we expecting that the applicant’s answer provides specific details, operational or communications, etc.”
* Leadership replied that “If it is generally reasonable then it would pass. Recall we are attempting to weed out frivolous applications for variant label(s). So something senseless would fail.”
* The ALAC representative to the team volunteered to have the ALAC review the updated text for 3.5 and 3.6 as the original language was generated by them.
* The chair discussed the leadership changes in the text of 3.6 to allow evaluators to be reasonable in their scoring. In the estimation of the chair, it will be highly unlikely that an application would fail.
* ACTION ITEM: The ALAC will review the updated language in Rec 3.5 and IG 3.6
* Rec 3.7 was described, along with pointed discussion on the updated language for IG 3.9
* One team member asked about the impact on Registry Service Provider, including current RSPs?
* The chair shared that the intent is that there will be no impact on current RSPs as the tests are not retroactive and will only impact new applicants.
* The team member asked about in the future if there are three tests that will have to apply for a new applicant. If an existing gTLD does not comply because the RSP does not have the requirements on new RSPs implemented, why would they be allowed to continue to offer their services?
* Another team member asked about the impact on registry service operators managing multiple different gTLD backends.
* For example, if an RSP manages five different TLDs and one of them is a new operator that is transitioning in, that requires compliance with the new tests, how are they going to manage the split between the new and old requirements?
* They suggested decoupling the capture of learnings and what needs to be done, as to not talk about implementation. Changes could be applied in the future such that operators will have ample time to reflect changes and gain compliance.
* A member of the team had considered this language as meaning ICANN would develop and require the specific clauses, but there is a challenge that there is no one standard
* The intent of the guidance is to complete research into the implementation of this round of the gTLD program to inform best practices for future rounds.
* ACTION ITEM: The team will deliberate on IG 3.9 and how to proceed with the specifics of the application process
* Rec 3.10 was described, and the team detailed the global change and editorial changes made to the wording.
* Rec 3.11 was described, including the global change and a discussion on the four allocatable variant labels, with no substantive changes.
* Rec 3.12 follows the global change.
* Rec 3.13 covers the potential discount for registry operators and the discretion given to ICANN org to decide on individual cases and the grammatical change to the recommendation to clarify this point.
* Rec 3.14 contains minor wording changes and Rec 3.15 there are no edits. In these two recommendations 2012 and IDN remain, not following the global change, as they contain specific carve outs for these cases, nullifying the global change.
* There were no objections from the team from 3.10-15
* The vice-chair implored the team to review the document before meeting #95 next week
* AOB
* The chair ended the call
Dan Gluck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20230901/923f7395/attachment-0001.html>
More information about the Gnso-epdp-idn-team
mailing list