[Gnso-epdp-idn-team] Notes and action items - IDNs EPDP Meeting #66 - 19 January 2023
Emily Barabas
emily.barabas at icann.org
Thu Jan 19 14:59:49 UTC 2023
Dear all,
Please find below the notes and action items from today’s meeting on Thursday, 19 January 2023 at 13:00 UTC.
Kind regards,
Ariel, Steve, and Emily
Notes and Action Items - IDNs EPDP Call – 19 January 2023
Action Items
Action Item 1: Staff to draft recommendations on String Confusion Objections and Limited Public Interest Objections consistent with draft agreements presented in slide 4, including text on the outcome of the String Confusion Objection.
Action Item 2: Staff to draft recommendations on Legal Rights and Community Objections consistent with agreement to use the option 1 approach.
Action Item 3: Staff to draft recommendation to specify the meaning of blocked variants in the context of the hybrid model.
Action Item 4: Staff to research existing IDN gTLD registry operators are community or geo TLDs?
Action Item 5: Staff to draft recommendation extending Recommendation 2.8 as it applies to ROs applying for new variants, and also that the documentation requirements that apply for the primary will also apply to variants of GeoTLDs and community applications.
Action Item 6: Staff to draft language that the .brand variants must meet the same requirements as the primary and operate as a mark.
Notes
Notes – IDN EPDP – 19 January 2023
Welcome and Chair Updates
* The Board is interested whether our phase 2 work has any impact on the next round.
* The leadership team has an initial discussion with Karen Lentz’s team at org and these discussions are continuing. The leadership team will share an update when there is additional information to provide.
* Additional draft text will be shared with the EPDP Team in the coming days for review.
* There is org input related to both charter questions E2 and E7. This will be reviewed as part of the relevant agenda items on today’s call.
Deliberate on Charter Question E2
* Slide 4 – Draft Recommendations Based on EPDP Team Agreement
* Clarification: Is it correct that recommendation 3.1 would be a sub-set of the recommendation on String Confusion Objection?
* Response: Correct. 3.1 is the baseline for what strings must be included in the objection process (requested and allocatable). The String Confusion Objection extends beyond the baseline as the basis for the objection (non-requested allocatable and blocked variants may also come into play).
* Question for input: On the outcome of the String Confusion Objection – Is a recommendation needed given that would be in line with what SubPro recommended?
* Chair view: For completeness, we should have recommendation stating that it is consistent with SubPro. This will connect the dots.
* Support expressed for having a recommendation for completeness.
* Question: What would the 1.b. outcome look like?
* Response: Outcome of the String Confusion Objection depends on the objector – whether it is an existing RO or applicant. If an existing RO is the objector and it prevails, the application is ineligible to proceed. If it fails, the application can proceed. If the objector is another applicant and prevails, the two strings will go into a contention set. If the objection fails, both applications can proceed. These outcomes are no different from regular TLD applications in the 2012 round.
Action Item 1: Staff to draft recommendations on String Confusion Objections and Limited Public Interest Objections consistent with draft agreements presented in slide 4, including text on the outcome of the String Confusion Objection.
* Slide 5 – Legal Rights & Community Objection Option 1 – Pending EPDP Agreement
* Support expressed by members on the call for pursuing option 1.
Action Item 2: Staff to draft recommendations on Legal Rights and Community Objections consistent with agreement to use the option 1 approach.
* Slide 6-7 – Legal Rights & Community Objection Option – ICANN Org Input
* Glossary may be beneficial in addressing org input regarding blocked variants.
* Org comment: It will help to have a glossary. There are some cases where mixed scripts are allowed. In those cases, when we are developing the glossary, those exceptions could be noted.
* Org question from slides: Will a holder of a mixed-script trademark be allowed to file an objection?
* Comment: A trademark can be mixed script, but a DNS label cannot. The mark holder would need to “translate” its mark to a valid DNS label. Is there actually a problem to solve for with respect to the org comment?
* Comment: Maybe the org comment gets at a trademark holder who has a mixed script mark, but doesn’t have a TLD and wants to file an objection.
* Clarification: The mark holder does not need to be an applicant.
* Comment: Org comment is about whether someone is allowed to file an objection. There doesn’t appear to be anything that prevents them to file an objection as long as they are a trademark holder. The question is whether they can make the case to win the objection.
* Comment: Mixed script strings are not allowed in the DNS, so likely variants of those strings are also not applicable.
* Comment: The purpose of reviewing the org input and option 2 here is to make sure that everyone is aware of it, even if it is not applicable given that the EPDP Team is pursuing option 1.
* Summary: The review of these comments do not appear to change the group’s direction of travel in favor or option 1.
Action Item 3: Staff to draft recommendation to specify the meaning of blocked variants in the context of the hybrid model.
Deliberate on Charter Question E7 / B5 (evaluation criteria for gTLDs with restrictions)
* Slide 9 – Draft Recommendations Based on EPDP Team Agreements
* Are these points consistent with the EPDP Team’s understanding? Would this extend to the newly applied for variants of existing TLDs?
Action Item 4: Staff to research existing IDN gTLD registry operators are community or geo TLDs?
* Comment: If there are existing IDN gTLD ROs for community or geo TLDs that have been operating, there is a limited number. Do we really need to put them through the task of getting additional supporting documentation/endorsement, understanding that in applying for their variants, all they are doing is completing the set and supporting the relevant language community? This is an area where there could potentially be an exception.
* Comment: GeoTLDs exist because they have asked for and received permission. If a RO applies for variants without getting permission, they are going to get into trouble with the relevant government. If the variant is going to represent a city or region, it needs to be supported.
* Additional support that for the idea that the same conditions need to apply for variants of GeoTLDs that apply for the primary. There is a specific definition of what a GeoTLD is. In addition, it you make an exception now for existing TLDs, you will have to make the same exception for those that apply for a primary string in the next round and variants in later rounds. In such case, it doesn’t make sense anymore.
* Comment: In developing the recommendations, we can make sure that the documents apply for the primary string and all of their variants. For existing gTLD ROs and future gTLD operators, it might not be possible to submit required documents for variants once again. If they submit the required documents, we agree that the documents apply to the primary gTLD and variants.
* Summary: for GeoTLD applications, the documentation requirements should still apply if existing TLD operators apply for variants.
* Question: For community applications, we would likely go down the same path. But the reason for a community priority application, documentation is submitted in order to get priority. Does that apply if the existing RO is applying for the variants?
* Comment: It is cleaner to get letters of support when there is an application for variants, but there might be exceptions.
* Comment: If there is a change of administration, there could be challenge of an RO applying for a variant.
* Summary: For community applications, to get variants, they need expressions of support, and for GeoTLDs, to get variants, they need to get government support.
Action Item 5: Staff to draft recommendation extending Recommendation 2.8 as it applies to ROs applying for new variants, and also that the documentation requirements that apply for the primary will also apply to variants of GeoTLDs and community applications.
* Slide 10 - Evaluation of Variant of .Brand TLDs & Relevant ICANN Org Input - Question for Consideration: Given that a .brand TLD must be identical to a registered trademark, should the requested allocatable variant label of a .brand TLD also be an exact match of a registered trademark? Should the applicant submit proof that the requested allocatable variant label is identical to a registered trademark?
* Note: If there is not expertise within the group to answer the relevant questions, this can be put out as a question for community input in the Initial Report.
* Comment: If the primary string operates as a brand but the variant does not, that might be a source of confusion.
* Comment: It seems difficult for variants to meet the requirement for a brand if the threshold for a brand is an exact match.
* Comment: A trademark is a well known string. If a mark is well known in different versions (for example variants in the RZ LGR scope) it’s plausible that the mark holder has certain rights and the necessary documentation to apply as a brand TLD for those variants. If a brand doesn’t have the protection, it may mean that they don’t have interest in operating a TLD. This feeds into the conservative approach of how many variants are put into the root zone. Extending the requirements for Brand TLDs to their variants is consistent with the conservative approach. In brief, it wouldn’t be a big ask to request that brand owners have the necessary documentation of rights for the variants in order to get the TLD.
* Comment: Trademark owners may register stings in different IDNs. It’s up to them.
* Question: It might not be the case that a brand has trademark rights to the variants. What is the purpose of having a restriction?
* Response: The primary label needs to be trademarked to meet the brand requirement. The question is whether there would be the same requirement for allocatable variants that they would also have to have a trademark.
* Comment: There could be a case where a famous brand has the trademark right, but not for a specific script.
* Summary: This topic may need additional input from the IPC. If the EPDP Team is not in a position to develop a recommendation, the leadership can put together two alternatives for additional input.
* Comment: We should not give more rights to companies than they have in the real world.
* Comment: In terms of trademark law, the rights are attached to one, distinctive mark. It can’t have variants in that sense. Any recommendations need to be in line with trademark law.
* Staff comment: It may not be straightforward to present two alternative recommendations. Option 1 has a simpler implementation. If we go with Option 2 and expand availability to non-trademark variants, we need to answer the questions from org about whether those variants will be .brands and what the operational implications may be.
* Comment: The whole point of variants is to prevent end user confusion. If you have a variant set with a brand, generic and something else, that will be confusing. If you have a variant set they should all be the same type of TLD. You don’t want a situation where a mark holder only has rights to one string, but gets to operate a whole variant set as brands.
* Comment: We are not saying that we are extending the rights. We agree that the variant set belongs to the successful applicant. The set is withheld for that same entity. No other applicant can apply for those variants. The question is for the RO who already has a brand TLD activated, what is the requirement to activate the next variant label? Based on conservativism principle, the applicant for the variant will need to present the same requirements to go through the application process, also in the case of a brand.
* Comment: ccPDP4 uses “delegatable” which is narrower than “allocatable” because there are additional requirements to be a ccTLD. This is similar to our discussion. RZ LGR may generate labels that are allocatable, but in the example of brands, it may be the case that they are not delegatable if they don’t meet the additional requirements. Would this comparison be useful in the EPDP Team’s analysis?
* Leadership comment: We could recommend that a brand must be identical to a mark and so must any allocatable variant, and see what input comes in through public comment and if that changes the direction of the group.
* Comment: The chances that a federal government / city mayor’s office signs something not meaningful are minimal.
Action Item 6: Staff to draft language that the .brand variants must meet the same requirements as the primary and operate as a mark.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20230119/9e4e338f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EPDP Team Meeting #66 Slides - E2, E7_B5.pdf
Type: application/pdf
Size: 730062 bytes
Desc: EPDP Team Meeting #66 Slides - E2, E7_B5.pdf
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20230119/9e4e338f/EPDPTeamMeeting66Slides-E2E7_B5-0001.pdf>
More information about the Gnso-epdp-idn-team
mailing list