ACTION ITEMS FROM THE MEETING:

• Staff will review the TMCH statistics as there may be as many as 30,000 DNL List Labels currently in the system
• Staff will Validate whether Section 4.1.3 would apply when an RO only intends to block variants.
• Staff to draft text along the lines of the recap. Response to charter question F1 will be drafted (including rationale and group deliberations. Also, investigations based on a team member’s comments will be addressed and brought back to the group for review.
• Staff will create a separate recommendation that is specific where any transfers of domains that are part of the variant set, the consequences should be the same.
• Staff will clarify in the text the definition for variant set. Expanding upon the previously stated definition that it is determined by the primary or source domain will allow the definition to better sync with the Subpro definition

• Staff should ask WIPO or other experts how they would interpret the current UDRP and other policies.

• Staff should double check whether the team confirmed earlier that if they are allowed to change the primary then they should be able to without enforcing deletion.
• Staff will add Implementation Guidance that - 

1. 1. The burden is on the complainant, so they will have to include all the names they wanted to suspend. The complainant should take the variant set into full consideration when filing the complaint. 
   2. Leave it open to RO if they want to suspend only the domain names in question or all variant labels in the set, depending on the RO’s policy and implementation

• Staff to draft the text for WG members to review for question F2
• The chair asked staff to discuss with ICANN org colleagues on the feasibility of RDAP changes to better denote / reflect variants and the primary / source domains.
• Staff should come back to the topic of matching guidance to ccNSO policy on Friday of the meeting to fine-tune. Leadership/staff can develop a straw person and bring it back to the group for discussion.
• Staff should add an implementation guidance to a pre-existing recommendation we’ve drafted or develop a new recommendation. Registries have their discretion to implement policies; however, they should take into consideration the SSAC guidance. It would be beneficial to reference SSAC 060 and leave it to the registries to implement themselves.
• Staff will work with leadership to develop some language to address the gap in recommendation 18 that could encourage registries to publish information relating to  existing domains and variants that do not have the same-entity principle remaining available. 
• The RySG will deliberate and get feedback on harmonization / variant tables
• The Contracted Parties and ICANN org will discuss how to include the definition of harmonization for registries to check if their tables are harmonized to the correct level.
• For Variant Domain Name, Staff needs to adjust text regarding “registered in different ways”, which implies different mechanisms.
• Staff should draw a picture of the life cycle, preferably of the domain set of variants. Without it there may be confusion (different interpretations of where the domain exists.)
• D4.6 should be changed to allocated as it includes the lifecycle stages of redemption, pending delete, where the same-entity principle should be upheld.
• D6.7 should be modified to reflect that it can be allocated as variants that are currently EPP Hold or don’t have name servers (not activated) must still be included in the transfer.

NOTES FROM THE MEETING:

DAY 1 

Session 1

Action Items:

• Staff will review the TMCH statistics as there may be as many as 30,000 DNL List Labels currently in the system

Notes:

The chair welcomed everyone to the meeting and the team introduced themselves going around the table and virtually.

The chair thanked everyone coming from the GNSO SPS meeting in Washington and then passed it off to a staff member for logistics, including lunch, dinner, and snacks.

Staff began to introduce charter question F1, with discussions from the team on the Trademark Clearinghouse.

Expanding on the TMCH sunrise service, including the processes and order of operations for the mark holders and potential applicants.

Also explained were the inclusion of Domain Name Labels, rules for Matching for the Sunrise provision and Claims Services.

There was a question on if “Spaces” are omitted from the matching rules? Staff will look into this

Trademark owners provide the labels but the TMCH is the body that determines if the labels are eligible. There 10 labels included in the original fee, but more can be added for additional costs.

Statistics were presented for the trademarks that are verified, DNL List Labels, and SURL List Labels. 

ACTION ITEM: Staff will review the TMCH statistics as there may be as many as 30,000 DNL List Labels currently in the system.

The provisions for languages and scripts through the TMCH were defined, with a question for variants in the TMCH.

Regarding the variants, TMCH does not verify trademarks and supports any language that grants trademark rights.

“TMCH does not track if the TM is still existing even the next day after the TM pays to TM" per a participant. 

The chair discussed that the Trademark Clearing House is a separate service from registry/registrar observations. It is optional. Is this discussion relevant to the EPDP?

One team member asked the role of the EPDP in determining any actions in this process.

It was suggested by another member that the registry operator would have to verify if the variants are active trademarks, but otherwise the TMCH doesn't have any actions to complete.

Different team members described the process for the claims process. The effect of having a trademark on, for example, not every variant that is being applied for was described. There is protection at the top level for the primary TLD, and variants even without the trademark there may be protections due to the process.

The claims phase is meant as a safeguard for registries to be alerted there may be a potential applicant that could infringe on the mark. There could still be a registration, but there is a warning that could set forth actions to stop the process. Updating this process for variant labels might be as simple as that warning saying a variant is being attempted to be applied for, per a team member. 

It is troubling that one part of the ICANN ecosystem recognizes variants and one part doesn't per a different team member.

The chair asked if the same entity principle provides the protection at the second label for the TMCH.

The sunrise period may not have any work for the EPDP team, the claims period might, per two team members. 

A team member asked a question on if there is a conflict, does the EPDP team have the remit to make an action? 

Staff expanded more on the abilities of the TMCH to recognize accents and diacritics as an ancillary service of the TMCH. Also described were third party services that are not mandated and outside of the policy remit to discuss and create policy for.

Are these ancillary services provided inside and/or outside of the 90 day claims period? They are provided after the claims period. During the 90 day claims period, the examples on the Ancillary Service Ongoing Notification slide do not carry the same protections.

The chair ended the session by asking about the implication of the same

Session 2

ACTION ITEMS

• Staff will Validate whether Section 4.1.3 would apply when an RO only intends to block variants.

NOTES

Tentative outcomes - for Sunrise, does not seem to require adjustments. Still need to discuss Claims.

Continuing now with discussions about the elements in the Registry Agreement. Reviewing slide 14, in respect of 2.4.2. 

Confirmation that is more or less accurate except for potentially bullet 4 where the domains are not necessarily registered and activated, but it’s more of a request/reservation. This allows for resolution of multiple requests for the same strings. It might make more sense to just allow for the variants to be registered after Sunrise since no other party will be able to do so (i.e., same entity rule).

Re: 4.1.3, would this also apply if the policy only allows for blocking, or does it only apply for Allocation. May need to validate that this provision would apply if the registry only blocks variants. Question for this group - does this need to be policy or is it sufficient to have the requirement captured in the RA?

For the end of the Sunrise, all blocked variants will be relevant.

Reviewing slide 15, in respect of 4.1.3. Would this work the same way if the variants are blocked? It seems to be the case since the language of 4.1.3 says ALL labels. When applying IDN tables to Exhibit A, the registry must state whether variants will be allocated and/or blocked. 

Action Item: Validate whether Section 4.1.3 would apply when an RO only intends to block variants.

On slide15, it probably means that bullet 2 should include all variants, not just allocatable ones. This group might want to consider how to pass the work on to RPMs.

Question about the last bullet, allowing the potential registrant to elect to proceed with the registration. How does this impact the same entity requirement? Reminder that claims only flags, does not prevent. 

Claims do not have an impact on how domains are registered, so will have no impact on the same entity principle.

Reviewing slide 16 and 17, in respect of SAC 060 and Recommendation 10. There may have been a misunderstanding of how registries query the DNL. In reality, registries pull the list (e.g., once per day) and are able to use that as the reference list, so the downside of a large number of transactions is inaccurate. In addition, registries have different IDN tables, so the list of variants will be different for different TLDs.

Variant calculations belong with the Registry. Having the TMCH provider calculate variants would expand the role of the service and would potentially pass on costs to TM holders. Recs 10, 12, and 13 might be implicated, not just 10. However, 10 seemed the most relevant.

Note, these recommendations were made a point in time, so what has occurred since has simply superseded the recs.

Reviewing slides 18, 19, and 20, in respect of the RPMs PDP Phase 1 Final Report and relevant recommendations.

Question about Recommendation 4, which says that exact match rules must be maintained. Clarification that the recommendation is applicable to the TMCH provider, not necessarily the registry operator.

There are variants at 2 levels. Is there anything that needs to be addressed in respect of top-level variants for RPMs? It seems that existing rules would apply across variant TLDs. In addition, the TMCH operates against labels, not full domain names.

Assumption that the RPMs group would have looked at provision 4.1.3. A possibility for this group could be to point to work that took place in a different forum (e.g., affirmation).

Question about the scope of this EPDP Team’s remit: can it provide recs to the TMCH, or just contracted parties? Must also avoid expanding legal rights while also respecting variants. It seems that TMCH comes from policy recommendations, so policy recs needed to modify.

Returning to slide 13 and Section 4.1.3, it talks about TLD (singular). Would this apply across the variant set? The recommendation at the top-level says that there must be a single RA, so consideration might be needed. However, since each TLD and variants must adhere to the RA, we might already be covered. SubPro rec and SAC060 might also need to be considered.

Need to take a step back and take into consideration existing work (e.g., SubPro, SAC060, and RPMs) and see if all of these inputs are compatible with what this group wants to accomplish.

This EPDP Team may want to recommend that each TLD and any variants must have individual sunrise and claims periods. The Qualified Launch Period might facilitate the handling of variants as variant TLDs are launched.

It might be confusing if a registry were to roll out its TLD and variants at different times. This would be confusing to potential registrants. May want to have this question asked in the new gTLD application. Unclear how something like this could be evaluated.

This group has not agreed that variant TLDs must launch at different times. In fact, the group has agreed that this is not a requirement.

There seems to be agreement that each TLD and variants must comply with requirements, but may need to consider implications for all variants. 

For Sunrise/Claims, should avoid having them overlap. The RO should take this into account. The EPDP Team could make a recommendation in line with this. The overlapping Sunrise aspect is more problematic for the end of the period, but not a concern for a first-come-first-served model. 

Subsequent launches of variants shouldn’t seem to require additional Sunrise/Claims periods. Conceptually, it does not seem like it is a separate release of new names. TM may not have elected to register their domain names during Sunrise. Same might apply during Claims.

In fact, it is possible that there could be different variant TLDs since different languages could be targeted (e.g., Urdu versus Arabic). Agreement from others that it may be the case that TM holder only cares about a particular variant TLD.

Reminder that at the top-level, the EPDP Team recommended that SubPro timelines must be adhered to, but the registry may delegate at different times and in the sequence that makes sense for them.

A primary and its variants can be delegated with a large gap.

Slide 21: discussion questions. For question 1, it does not seem like the TMCH matching rules should be expanded, which is also in line with RPMs recommendations. For question 2, it seems that there is sufficient flexibility, but may be worthwhile to affirm what is captured in the registry agreement.

Note that the provisions apply if a Registry Operator implements a variant policy, which does not differentiate between blocked and allocatable. 

Agreements: 

• TMCH matching rules should not be expanded. 
• No issues with Sunrise.
• There might be changes for Claims, but this would be more procedural. There does not seem to be an impact for the same entity. 
• Affirm/confirm what the RPMs group agreed to, 

Potential open issue:

• Confirming what “implemented IDN registration policies” means, especially in reference to a team member’s concerns. 
• Whether or not overlap against Sunrise/Claims is problematic or not, and whether the group needs to do something.

Session 3

ACTION ITEMS

• Staff to draft text along the lines of the recap. Response to charter question F1 will be drafted (including rationale and group deliberations. Also, investigations based on the team member’s comments will be addressed and brought back to the group for review.
• Staff will create a separate recommendation that is specific where any transfers of domains that are part of the variant set, the consequences should be the same.
• Staff will clarify in the text the definition for variant set. Expanding upon the previously stated definition that it is determined by the primary or source domain will allow the definition to better sync with the Subpro definition
• Staff should ask WIPO or other experts how they would interpret the current UDRP and other policies.
• Staff should double check whether the team confirmed earlier that if they are allowed to change the primary then they should be able to without enforcing deletion.

NOTES

Staff recapping previous two morning sessions - all in agreement

Action Item: Staff to draft text along the lines of the recap. Response to charter question F1 will be drafted (including rationale and group deliberations. Also, investigations based on a team member’s comments will be addressed and brought back to the group for review.

New topic: Charter Question D6a

Re: activated vs. allocated - should staff use a different word? (terminology question) - will be brought back for group discussion. 

Question to Group: Does the group believe Prelim. Rec. 7 is enough to address the Charter Question?

The Rec. before is more general regarding transfers, and here is specific about UDRP. Phase 2 of RPM WG is ongoing and will be discussing RPM, so the team should have something to say about it which can be provided as input to the UDRP.

If UDRP doesn’t change, then the same entity principle should apply and the entire set should be transferred by default. Staff should state clearly that the principle of IDN variants is important for the security and stability portion. It shouldn’t be deferred to a panel without specialized input (RZG panel, etc.).

In all standard cases, even UDRP - those variants should not be separated and the same entity principle should always be upheld.

ACTION: There should be a separate recommendation that is specific where any transfers of domains that are part of the variant set, the consequences should be the same.

Potential Issue:

• UDRP is a registrar process (registries don’t interfere in it.) The domain is transferred to the winning party if it was a complainant. If not, it returns to the previous. There can be strange consequences. Two parties can have the rights for the same set of primary strings and its variants in different situations. To understand who’s going to win and why is difficult. The team needs to consider the option of inherited domains not being treated under this rule until the situation is resolved and one party has control.

In the case of disputes in UDRP, it’s resolved against the other person. It’s important to know which applicant is successful.

Whoever owns the TLD will have the IDN table, but the registrar holds the name - that’s where the disagreement is. The consequence of the UDRP being successful is that the registrar has to transfer that name accordingly. Therefore, the IDN table might not be a consideration.

To Clarify: The registry holds the table, and the registrar implements it. The domain name is transferred between registrars (and stays between TLDs) - the same TLD, but the 2nd level is controlled by the registrars which are transferred.

Note in chat: For a registry it is URS, but it works differently (the situation is frozen with NS servers directing to a website saying that the domain was lost in URS. IDN tables are held by a registry with a copy on the IANA website.

In terms of UDRP, it can be a transfer but it can also be a delete. 

There are things the team should think about: 

• A scenario can exist where a cybersquatter registers a name with intent to hold variant and hold a mark holder ransom. Current UDRP might not be able to handle this, though in future they should be able to recognize a variant is in a variant set - in those cases the transfer may happen (the entire set) and may be updated to a different primary leading to a different language tag and set of variants.

• The set of variants will remain the same if harmonized; but in a case like this, the RZ LGR can play a role in the consideration of the UDRP and also how the transfer happens (what may or not be done immediately after the transfer).

The question is about: If the outcome of the UDPR is a transfer, what’s the treatment? 

Team members requesting an overview of the UDRP for more information (Staff providing overview)

Is there IDN specific data among the UDRP stats? Would be helpful to know.

The current UDRP process is unaware of variants. Will this add variants into this process? Some complaints are acknowledged that the complainants are right, so what happens in those cases?

The text is discussing the result of the UDRP and not necessarily the process - it’s an individual domain name and doesn’t account for variants. It’s not within our remit, but the question is if it’s about only one specific domain, then some variants are in use and not an issue. If the same entity principle applies, then it will all go to whoever won the despite, even if there are no problems.

Two possible outcomes:

• Cancellation: no problem here because we’re talking about 2nd level. The other variants can still exist.

Note: That’s an assumption and not sure if it’s the right or wrong one.

• Transfer of the domain (more difficult). One is transferred, but what about the others? We’re exploiting the concept of the same entity, so if it is intended to keep the same entity, then why is it that one registrant gets one variant and not the others.
• The team agreed on harmonized IDN tables, so don’t think this is an issue.

Re: Cancellations:

• When the cancellation occurs, it’s up to the registry policy to determine whether the whole set is deleted with the variant or if they allow the already activated variants to continue to exist (if so, to change the primary if needed) - the same situation if the registrant wants to delete one of its domains within a variant set, and it’s up to the registry.

Re: Transfers:

• It’s clear that in the UDRP outcome, if the domain name needs to be transferred to another registrant, then the entire set needs to be transferred as well. The potential problem would only be if there are two UDRP cases (1 case regarding one, another regarding a variant, and if the losing entity starts a case with another variant that was transferred in a similar situation and they win the case) - the whole set would need to be transferred or else it’d be opened again. Separation of variants might be required then, if by law those variants have to belong to different entities.

If the decision is to transfer, the whole set would be transferred, but if there is entity A and entity B (and entity A won a case and now needs to acquire the domain name) and entity B holds the primary and another variant; then A needs to transfer to B and B won. 

In terms of variants, they are looked at differently. It is possible to have a variant that infringed on an existing right and another that didn’t. The UDRP then was giving a judgment on one variant only - how does that work with the splitting?

Question: It’s not up to the registrant to make a decision, so what would happen if there is a judgment on one and the registrant says they will delete the others?

Answer: If the UDRP says one domain has to be deleted, then the registrar will have to delete it and it’s up to the registry policy and needs to be determined if the entire set of activated variants are deleted at the same time, or a single domain and other variants may remain existing. Can also occur without UDRP and should behave the same.

Question: If it’s a variant, and the primary is deleted, what happens to the variant?

Answer: It depends on the registry. If they allow primary domains to be deleted then the variants can keep existing and another primary must be selected. But if the registry says no (variant attributes model - variants are just attributes of existing primary domain names) and if the primary is deleted then the whole set is removed.

There couldn’t be a situation whereby a panel could award a splitting because we’re talking about only one registration. If the registrant is considered to be abusive, then the current UDRP has to mean that the entire set is transferred. If in the future there may be a different situation and the policy should warn registrants as they go through that UDRP situation.

Important Note: 

• Terminology about delete or cancellation of the name is critical. It is possible to deactivate a primary domain, but if you delete the entire registration the entire package should go. If you deactivate the primary, you have to put another in place. (You can’t calculate what other activated variants could be).
• The primary may be deleted and if the UDRP allows such a nuance, then you can deactivate the current primary and reactivate a new one, but it’s currently not in the UDRP process.

ACTION: The team should ask WIPO or other experts how they would interpret the current UDRP and other policies.

Comment: The charter question is very specific - about what happens in a transfer situation in the result of a UDRP and the applicability of the same-entity principle. The team has to draw a line on this thread and it can be picked up in the future.

When UDRP makes a decision of transfer, it’s because of 1 of 3 things:

1. Domain is identical or confusingly similar to trademark
2. Respondent has no legitimate interest
3. Bad faith

If a decision has been made in regard to a variant due to one of those 3, then it makes sense that this applies to the full set. There is nothing in the UDRP that says so (the problem).

Question: If the primary domain is deleted then the whole set must go. Has the team decided on if a primary domain name must be active? (Discussed it to be open to the registry to say that a registrant may register variant domain names, but have the primary domain name not activated). Unclear about it and want to confirm. 

Answer: Primary means it’s been registered, so if the primary is deleted, it’s hard to pick a primary from the variant set.

ACTION: Staff should double check whether the team confirmed earlier that if they are allowed to change the primary then they should be able to without enforcing deletion.

Clarifying:

• WIPO says respondents can file a lawsuit if not satisfied with the result.
• There may be external factors that may prevent a registrar to transfer a domain all together (i.e: a court order).

It’s fair to mention something that is non-negotiable for us. Whether or not the team will consult an expert, concerns should still be explicitly laid out. If something has been in place for 20 years, it might not be relevant and the team should flag it.

Note: 

• A court order may not technically allow a registry to register different domain names because the activations are tied up in a single/same registration (not feasible). Wondering whether in the rational, something like that should be noted, depending on the registry’s technical set up.

Comment: Registries/registrars are entities of certain jurisdictions so they have to comply with their jurisdictions. If they don’t they will be breaking the law and must do what the courts say they have to do. They don’t care about variant sets, and it will take a long time for the idea to propagate the practice. If the court forces one of the registrars to do something with a domain, then they will do it and local laws always prevail - must be careful.

If a variant exists through an EPP update, a split won’t be possible, but if it’s existing with an EPP create, then it will be possible (though not very related to this conversation).

Summary of Action:

• The same entity applies to a transfer if there’s a UDRP decision that says the name must be transferred. And as part of the transfer, the same entity principle applies, and the set goes where the contested domain has to go. However, the team recognizes there is a shortcoming in the UDRP itself because it doesn’t account for variants and the team will make a suggestion in the report that this should be addressed. Not how, but just flagged.

Question: When the text says variants it includes variants at both the 2nd and Top level right?

Answer: Only using it at the 2nd level.

Follow-up: The same-entity requirement goes beyond just the 2nd level and into variant TLDs as well though.

ACTION: Staff has to talk about variant set definition. The text previously said it’s determined by the primary or source domain name (the team defined per domain name, but haven’t fleshed out when a primary has a variant, what is the set?)

Comment: SubPro suggests that S1/T1 and S1/T1V1 have to be the same entity. If there is a transfer S1/T1, then S1/T1V1 has to be transferred as well.

Restatement: Staff will clarify in the text the definition for variant set. Expanding upon the previously stated definition that it is determined by the primary or source domain will allow the definition to better sync with the Subpro definition

For this purpose then, variant set means top level and second level and all variations.

Suggestion on Terminology:

• IDN variant domain set (includes TLD) IDN variant domain label set (can be just the 2LDs)

[Staff providing overview of URS]

A single proceeding could be for a pack of domains - 15 domains at once - if the other party is the same for all of those (potentially across many as it’s not written).

Note in chat: 2.2 Complaints listing fifteen (15) or more disputed domain names registered by the same registrant will be subject to a Response Fee which will be refundable to the prevailing

party. Under no circumstances shall the Response Fee exceed the fee charged to the

Complainant.

General Question to Consider for Group: Do you believe what was written for Rec. 6 and the Rationale are already covered in Rec. 7 or should the team create a separate recommendation to clarify for URS?

Question: What happens to a domain if it’s locked?

Answer: When the domain is locked, it continues to behave the same way as it used to. But when suspended, it still resolves, but the name servers change to a predefined name server that shows the domain is suspended (other services such as emails will stop working as the original zone file is not active in the DNS anymore).

Question: Do other variants have the same content or should the team not refer to the reason for which the switch happens?

The UDRP approach can be very similar, the whole principle for URS is to suspend the domain - it’s clear that the registrant has been acting abusively with registration. Without nuance in the URS system, the default should be to suspend the entire set. When/if they review, they should consider this and if they want to do more nuanced changes, they should consider all of our conversations.

The use of the URS is when someone puts forward a registration (in either bad faith or good faith) and they infringe on someone’s rights, and that has to be suspended. If the registrant has registered more than just this variant, then not all of the variants are infringing on the rights of the others.

Comment:

• During URS suspension, the name server is redirected to the website and says “this domain was lost to URS” and nothing more. There is a misconception that URS is a cheap replacement of UDRP; however there has been a situation where a large company had their name frozen for more than a year due to not realizing that it’s a bad idea to gain control of a domain through suspension. Also URS rules define only one registration process. Could be 15 but within the same TLD.

• Rights cannot be granted for something for which a 3rd party doesn’t have trademark rights.

Clarifying:

• Only the domain which has the URS case should be suspended and not the whole set? The entity starting the URS has the opportunity to put the variants also into the URS case because they can have multiple domain names - if they don’t think it’s just related to a single domain, then they can add all variants to that and test the whole set. This may be problematic if the variant set of allocated domains are larger than 15, but in that case, they might have to create a new URS related to that.

Session 4

ACTION ITEMS

1. Staff will add Implementation Guidance that - 

1. The burden is on the complainant, so they will have to include all the names they wanted to suspend. The complainant should take the variant set into full consideration when filing the complaint. 
2. Leave it open to RO if they want to suspend only the domain names in question or all variant labels in the set, depending on the RO’s policy and implementation

• Staff to draft the text for WG members to review for question F2

NOTES

Question D7a: Should the suspensions ordered by the Uniform Rapid Suspension System (URS) or any other dispute resolution mechanisms be treated the same way to follow the “same entity” requirement?

• Option1: suspend only the domain names in questions. 
• Option2: all domain names in the variant set are suspended. 

Points supporting option1: 

• This is a rapid process and the compliant file for specific domain names, therefore, it should only affect the compliant domain names. 
• Other variant labels may not be registered or activated, therefore, not technically possible to suspend. 

Points supporting Option2:

• URS means there is some infringement engagement with clear evidence, therefore, it should be suspended the entire set by default. 

Conclusion: Option1, only affects the domain names in question. Compliant responsible to file the complaint for all domain names required to be suspended.

Action Items: 

• Add the Implementation Guidance that - 

1. The burden is on the complainant, so they will have to include all the names they wanted to suspend. The complainant should take the variant set into full consideration when filing the complaint. 
2. Leave it open to RO if they want to suspend only the domain names in question or all variant labels in the set, depending on the RO’s policy and implementation. 

Questions F2:In order to ensure that the “same entity” principle is maintained, what are the additional operational and legal impacts to the following RPMs that are not considered in the above charter questions, which mostly concern the outcomes or remedies of dispute resolution procedures or trademark protection mechanisms? 

• TMCH and its Sunrise and Trademark Claims services 
• URS 
• TM-PDDRP (Trademark Post-Delegation Dispute Resolution Procedure) 
• UDRP

Note: 

• TM-PDDRP already mentioned in the Phase1 Final rec 7.11.
• Legal court case out of ICANN? 
• Should the WG recommend ICANN org to focus on the outreach to multistakeholder to be aware of this situation?  
• Perhaps GAC or the competent jurisdiction where the ROs reside. 
• RPM Phase2 WG (charter drafting at the moment) 
• Some change to the registrant agreement could be suggested. 

Action Item: 

1. ICANN staff to draft the text for WG members to review. 

Question D8:What should be included in the WHOIS/RDAP for variant domain names (both the IANA whois and the Registry WHOIS)?

• This may be missed from the IDN EPDP Charter but it was brought up early when the WG started. 
• For variant domain names, when the RDAP query happens, what should be the responses. 
• Is there any additional details if the primary domain name is queried? 
• Each side should have some policy to govern and some flexibility for Ry Rr implementation.

RDAP and WHOIS query are about who responds to the domain name, so it points to the contact information. 

Then there are 4 kinds:
(1) registered domain name

(2) allocated but not activated domain name 

(3) allocatable variant domain name

(4) blocked variant domain name

• (1) may not need any changes in the current RDAP. But (2) and (4) may need more discussion. 
• ICANN org should contact CPH Tech Group to review the implementability possibility. 
• A member of the registrars shared examples of current implementation by CORE. 
• .cat ( https://whois.nic.cat/ and https://rdap.nic.cat/ ). Variant for .cat is implemented by using the attribute mode, therefore, one record for a variant set.
  https://rdap.nic.cat/domain/nic.cat (no variant)
  https://rdap.nic.cat/domain/fundacio.cat (have allocatable variant) 
• .sport each variant is registered as one record https://whois.nic.sport/ try “sumo.sport” 
• .پاكستان (Arabic Basha) http://s.corenic.org/s#l=%D9%BE%D8%A7%D9%83%D8%B3%D8%AA%D8%A7%D9%86 
• WHOIS/RDAP is for contact information. What is possible to register or other technical details should be dealt with in the EPP. 
• .ASIA implementation example is to point to the IDN table and let the Rr calculate. 

Question D8.1: Are there any additional data element(s) needed with respect to variant domain names? 

• How to respond if there are variant TLDs as well? 

Question D8.2: If the answer is “yes” to question 1, what data elements? 

Question D8.3: If the answer is “yes” to question 1, how should they be treated? (e.g., collected, generated, transferred, disclosed)

(TBC) Conclusion: 

• At the minimum, the activated variant domain name should be included in the response. nThe remaining information is a ‘Should’ 
  

DAY 2 

Session 5

ACTION ITEMS

• The chair asked staff to discuss with ICANN org colleagues on the feasibility of RDAP changes to better denote / reflect variants and the primary / source domains.

NOTES 

The chair opened the session with remarks on the team dinner last night and passed over to a staff member to summarize the first day’s discussions. This included topics such as the Trademark Clearing house, overlapping sunrise and claims periods, and WHOIS / RDAP. 

On the D8 Discussion question, staff asked the team if there needs to be further discussion. Some thoughts from the team included that if the variants are wished to be seen in the RDAP, it will be difficult because it produces thousands of records. It will be hard for registrars to fulfill their SLAs if there is that much more volume with variants. 

**Question on what is meant by primary. Might be picked up in the glossary, but important to note the value of the primary in the query.

The information has to be available in a clear way, but the chair noted that consistency in the profile will cover this.

Question if there is intent to have the query for a variant produce the primary result in a lookup, and that is probably what the team is going for, per yesterday's discussions. So a potential applicant can search for a domain they are interested in and see if there is any conflict with registered names.

Question if there are any RDAP changes that would be needed to accommodate this policy, but it was noted that this would be out of scope as it is implementation. There may be implementation guidance that could help but that is not the primary focus of this discussion.

The chair asked the team member who demonstrated a WHOIS query for variants if the site and output were ICANN approved, and while they were not sure, they think that while WHOIS can be customized, RDAP cannot. RDAP is standardized.

ACTION ITEM: The chair asked staff to discuss with ICANN org colleagues on the feasibility of RDAP changes.

Registry participant links

Adding to the IANA part of the equation, a team member discussed the IANA WHOIS and a website that lists TLDs. 

Registrar participant links

The page listing TLDs was explored. There may be a possibility to create a recommendation on the IANA database list to list variants.

One team member recommended a less prescriptive approach to the recommendation. Not explicitly IANA must do this, but maybe asking for a way to denote a TLDs has variants. 

In support of being less prescriptive, a chat message said: “we can convey our implementation guidance (as in we want linkages to show that they are part of the variant set) but how they finally display it would be up to IANA” 

A chat message from a team member is as follows: “note about .CHINA, IANA's position as I understand and inquired previously is that the 2 ccTLDs are NOT IDN Variants at this time, until the ccPDP is done and is implemented”. 

At the time of delegation they were not considered variants, they were made as exceptions to the rule. In the future the EPDP recommendations could be applicable to these edge cases. 

While the IANA DB list is authoritative, one team member asked if it is meant to be descriptive and fully featured. It is up to IANA to determine the content of the DB. In its current state, it is not meant to give further information.

Another team member shared that the html website DB may not reflect the current list of TLDs in the Root Zone. The .txt file above is what is kept current. 

The IANA site has additional information about, for example, the registry / registrar, but not fully featured. 

IN agreement that there is a suggestion or recommendation that the IANA DB reflects the location of the TLDs. The IANA WHOIS service requires a similar update at the second level. If there are active or registered domain names, the IANA WHOIS needs to be updated and reflect those new variables.

With regard to IANA DB having entries that do not exist and are there for historical reasons. There was a question on if the listing is on the site, it is still in the DB. It is not an artifact. It may not be used actively, but if it's in the DB it's in the root zone?

https://www.iana.org/domains/root/db/xn--0zwm56d.html  - TEST DOMAIN for an IDN TLD. 

THis is the HTML domain and not the txt DB. The txt DB is authoritative.

—

Moving over to IDN Implementation Guidelines for G1 and G1A.

G1 is about the vehicle to update IG 

G1A is about the potential legal mechanism for the implementation and guidelines for registries that wish to offer IDNs.

Staff gave the basics for implementation guidance (What, why, and who for / by).

For ccTLDs, ASCII is required but for IDN ccTLDs they have to commit to using the proper backend if they want to have IDNs

There was a question from a team member about the history of implementation guidance. Prior to guidelines, there wasn't a requirement for common technical standards. IG is a combination of policy and technical standards, while not being formally either (PDP for Policy or RFC for technical standards). In the 2012 round, these were included in the agreements (version 3 or so).

The board accepted the list of guidelines (4.4) and per request from GNSO it is deferred. 

Staff shared language in the contractual agreements as well as language from the IDN ccTLD past track process and ccPDP4 initial report.

Since the team is creating what are effectively policy and legal obligations, and the ccTLDs are just guidance, the team should acknowledge there are differences in the gTLD and ccTLD landscape but focus on the question at hand about the gTLD space. 

There was a question about the legal requirements for ccTLDs and the MOUs that ICANN has with some operators. There seems to be a variance across different areas, but is there a consistency element that needs to be reflected? 

A team member shared that ccTLDs are independent; there aren't many MOUs as ccTLDs are independent and bound to local jurisdictions. 

In developing policies around IDNs, per the chair, there is intent to have some uniformity across the gTLD and ccTLD landscapes. 

Staff provided a description of the update process for the IDN IG. 7 versions have been published between 2003 and 2022.

There was a discussion on the interventions from the GNSO 

Going through all of the different versions, with reasons for development, community contributors, and varied information, staff was able to provide historical context for the IDN IGs. Additional context was provided by team members who were around for the timelines. 

A team member shared that when the guidelines (1.0) were initially developed, there was a series of letters issued by ICANN to Registry Operators (https://www.icann.org/resources/pages/twomey-to-karp-2004-01-20-en) asking for a commitment to adopt updated guidelines. Over time, since day 1, IDN IG has been a defined and compulsory part of the deal with contracted parties. Not optional.

Session 6

ACTION ITEMS

• N/A

NOTES 

Starting with an ice breaker!

Continuing with review of IDN Implementation Guidelines versions on slides 59 and 60. All versions except v4.0 have been adopted by the Board.

Reviewing slide 61 in respect of v.4.0, including the numerous catalysts for working towards the new version. 

There is a very significant community-facing impact and potential impact on security and stability, which led to the participation of ALAC and SSAC participants, as well as the larger list of participants from the GNSO. Question about who convenes this group and how it comes about. Response, ICANN org was directed by the ICANN Board Variant Working Group. During a joint meeting with some GNSO members (including during GNSO working sessions), the Board asked staff to begin work on updating the guidelines.

The WG operated similar to an Expert Working Group and had duel chairs from the GNSO and ccNSO. This setup was reflective of the impact on the industry as a whole. Question of whether or not there was a charter. Call for volunteers is available here: https://www.icann.org/en/announcements/details/call-for-community-experts-to-review-the-idn-implementation-guidelines-20-7-2015-en

One of the first steps for the group was to establish a set of issues, which were reviewed by the community (potentially public comment as well). Slide 61 reflects the scope of issues/work.

Question about why there were two public comment periods. Logically, the likelihood is that there was a substantive change needed from the first public comment period.

Reviewing slide 61 in respect of v.4.1. Concerns with v4.0 were related to the fact that some elements were requirements, as well as that some aspects may be more appropriate for policy development. 

From v4.0 to v4.1, the WG did not meet at all. The updated version was a result of Board/Council discussions. There was also a question about when the guidelines are live. The Board confirmed that it’s upon adoption. At this stage, an important question is how the GNSO and ccNSO can work together to eliminate or minimize any differences.

The change from v3.0 to v4.0 follows past procedure.

Note that the WG did not include GAC members. The call for volunteers made clear what the participation requirements were to be.

Question about whether there is a need to coordinate with the Council now, or wait for outputs. Answer is that it may depend upon where this group ends up. The Council’s role will depend upon the outcome (e.g., CCWG, EWG, formal PDP, other). 

There are only limited ways in which to amend contractual requirements (e.g., contractual negotiations, PDPs). Coordination with the ccNSO makes this question potentially complicated. 

Note that PDPs within the GNSO welcomes the participation of the community broadly, so it might end up being an acceptable mechanism. This does not presume a certain outcome. The PDP is now inclusive. There might be a third path because there is such a strong technical component that ties back to the IETF.

Question about whether the EWG is a formal construct. Does not appear to be the case, though it is regularly used. The EWG for registration data was formed by the ICANN president and CEO, seemingly in an ad hoc manner. Some recollection that this concept was not well received by the community.

CCWGs cannot develop policy.

Need to ensure that the outputs of whatever mechanism is decided upon creates clear expectations for contracted parties and ICANN org alike.

Question about what implementation of IDN Implementation Guidelines looks like. Once ICANN org is directed by the ICANN Board, implementation falls to staff. The staff will coordinate with the contracted parties ad hoc, during ICANN meetings, and during the CP summit. As with other guidelines, ICANN org will file an implementation notice and identify an effective date. For v4.1, the timeline being worked towards for the implementation notice is the end of next year.

Seems to be two options: stay with current model but enhance, but the other option seems to be a PDP. The current process has seemed to work so far, so it might have some applicability.

There seems to be a challenge in timing. And there may be a difference in the subject matter that would warrant different approaches. In the instance of v4.0, the challenges were caught after the fact. What seems to be needed at least are more, or formalized checkpoints for awareness building and input from affected parties.

Reviewing slides 63-66 summarize the deltas from going from v3.0 to v4.1. Purpose is to help illustrate the nature of what is contained in the guidelines. In some instances, the guidelines create requirements. For Guideline 4, clarified that it is a requirement. Reviewing these slides, it may be helpful to consider whether the guidelines are best practices versus hard requirements, that might help to identify the formalized checkpoints.

Question of whether the guidelines represent technical requirements. Answer is yes, and in respect to security and stability. These should not be considered consensus policies. These requirements are instantiation of technical requirements from the IETF.

Question of whether it is important to define the purpose of the guidelines. Slide 54 helps with the “what” and “why” for the guidelines. It might be helpful to think of the guidelines as the glue from technical requirements. At www.icann.org/idns, there is a definition of the IDN Implementation Guidelines.

It’s helpful to look at the “why” as it will help guide the “who” and what mechanism. 

Starting with a readout from the RySG and their discussions. No conclusion, but discussed some ideas. Will need to reinforce that the IDN Implementation Guidelines are not just guidelines, but contractually required by Spec 6. Requirements include:

• Adequate representation from registries
• Clear language
• The work to develop the RDAP profile might provide guidance. This seems like a WG with ICANN org and the contracted parties.
• There should be technical expertise to support the work

For the RDAP profile, the understanding is that ICANN org developed a proposed profile and the contracted parties developed an amended version, which ICANN org eventually agreed to. The process to amend the profile in the future is via contractual negotiations.

Question about whether the terminology is challenging (i.e., calling them “guidelines” when they represent contractual requirements).

The issues are the same for gTLDs and ccTLDs, so a consistent solution is needed.

Question: does a PDP make sense to replace the current process for developing implementation guidelines? Preference is for an inclusive process that includes gTLDs and ccTLDs.

Clarifying question, would the PDP be about developing the mechanism or to develop the guidelines themselves? Answer is the latter.

The Council applied the brakes to v4.0 to the outcomes of an expert working group. Why weren’t the concerns of the Council reconsidered by the expert working group? What happened here is that the Council identified certain elements that were more appropriate for policy development, so sending it back to the expert working group would not have solved anything. The question here is perhaps instead, how do we identify earlier that there may be elements of the guidelines that go beyond appropriate scope.

The other factor that prevented going back to the group was that the expert working group had concluded its work.

The expert working group did not have a strict charter, so it may have been the case that the group extended beyond its remit. 

While the PDP process might not be the solution, it may be helpful to review the process to identify the proper checkpoints.

• For instance, during scoping, the catalysts can be identified, as well as proper scope of work.
• The initiation process helps to identify the membership.

For the triggers, the Board engages with the community and identifies when updates are needed. So it might be helpful to make the triggering process more robust.

Question about which entity manages the expert working group, or is one even needed. From the announcement, the number of members is reflective of parties involved in past iterations. For oversight, ICANN Board IDN-UA WG is kept up to date, so this seems to be the governing entity. 

Looking forward, perhaps the ICANN Board shall still own the process, but through the checkpoints, the GNSO/ccNSO Councils can have the opportunity to raise issues or apply the brakes. Even the past iteration shows the iterative process where the GNSO requested more seats and it was granted.

It seems that the mechanism at a high-level is appropriate, but additional structure needs to be developed. What are some ideas for enhancing the rigor of this process?

For membership, belief that it should be extended (e.g., to include the GAC, RSSAC). 

There seems to be at least two checkpoints:

• Issues identified/scoping
• When the proposed guidelines are completed, and prior to Board consideration

Another idea that might make sense is assigning liaisons from the Board and Councils.

For the Customer Standing Committee, specific expertise was needed. This sort of work may also benefit from having requirements in place.

Session 7

ACTION ITEMS

• Staff should come back to the topic of matching guidance to ccNSO policy on Friday of the meeting to fine-tune. Leadership/staff can develop a straw person and bring it back to the group for discussion.
• Staff should add an implementation guidance to a pre-existing recommendation we’ve drafted or develop a new recommendation. Registries have their discretion to implement policies; however, they should take into consideration the SSAC guidance. It would be beneficial to reference SSAC 060 and leave it to the registries to implement themselves.
• Staff will work with leadership to develop some language to address the gap in recommendation 18 that could encourage registries to publish information relating to  existing domains and variants that do not have the same-entity principle remaining available. 

NOTES 

Recognizing new observer joining us (NPOC Comms Chair: Jean Queralt)

[Staff leading a post-lunch holiday-themed ice breaker]

The chair recapped  Question G1

• re: IDN Implementation Guidelines, the vehicle to update currently in place is the one that is probably best to have
• Tailored call for expression of interest to identify what your area of expertise is

There needs to be a contractual/legal mechanism for gTLDs - what would be the mechanism?

Based on discussions had (G1) - not getting rid of implementation guidelines, do you think the question is addressed or are there gaps needing addressing?

The chair decided to move on as it does not need further discussion.

There has not been a thorough analysis yet - if anything is out of scope then it becomes an issue (the deferred items)

Outcome: The team should maybe defer this until recommendations from the IDN guidelines are looked at that were also deferred

Question: Suggesting for improving process for IDN implementation guidelines - how can we agree as a group on a method to suggest? Is it better to pick this as future work for this group or how should we proceed?

Answer: There were some good suggestions in previous notes that the team can look at to put together a proposal/develop text

Issue:

• The problem was CCWG (no existing procedure/nothing written in bylaws or any operating principles). When the Recs are delivered, and whoever is accepting the Recs, and they feel like a Rec should be revised/non-adopt the original language, there is no existing mechanism to follow in order to revise or send back
• For a PDP there are existing procedures - for a future group, whatever mechanism we’re suggesting should have this mechanism in place
• Who would be the manager of this mechanism? Board/GNSO/CCNSO can initiate a review and whoever initiates will be the manager (would that defy our work of not wanting it to be a PDP?)
• It’s a question of how prescriptive the team wants to be in designing or enhancing the current process. If it’s a PDP, the IRT would be the one to get into Implementation detail.

Question: We can have a pretty high level recommendation and leave the details to implementation, or should we be very prescriptive? We can think about this and come back to it during a future call.

Comment: For registries and contracted parties, predictability of how implantation happens is crucial. It can be seen if we can draw from and codify the way it currently happens rather than fuss over details.

This refers to the “trigger question” of how reviews can occur. The short answer should be “yes” but the prescriptive part on how to implement it is important. Staying at a higher level is better as it includes the CCNSO. If it goes to the Board, they will engage with the CCNSO for implementation. IG would be useful for the GNSO side to provide info on what we’d like to see.

The team has an opportunity to suggest some improvements to the IDN Guidance WG and the opportunity should be taken. Consulting with CCNSO may be useful.

• The membership perhaps need to be widened to other experts in the community
• And the trigger (GNSO or CCNSO). May need a default mechanism, if nothing has happened for a long time, it might need a review.

ACTION: Come back to this topic tomorrow to fine-tune. Leadership/staff can develop a straw person and bring back to the group.

We’ve completed Charter Questions and now look at potential gaps. Now examining deferred items.

Staff provided overview of Guideline 6a

Registries were triggered by IDN table format - the mandatory requirement to use XML format as noted in RFC 7940.

Question: How do we reflect this in our work? Is it a GNSO Council question? Or do we simply say this was addressed in the EPDP Charter Question C6.

Context: Speaking about the machine readable format, it seems the IDN tables are just the recommendation of registries/registrars—the requirement for all registries to redo all of the IANA tables for some reason. This affects registries and adds some working time, cost, and problems - hence registries didn’t like it.

Can a compromise be a grandfathering process for those who are existing to keep the IDN tables, and have to use the new LGR format?

Question: If we have a recommendation inconsistent with the guidelines, what do we do? Because we have a recommendation coming through a PDP, it will override the guidelines.

Answer: A letter was sent from the GNSO Council. Once this EPDP has addressed those guidelines, the Council should go back to the Board to inform them we’ve gone through the process, and tell them that for these guidelines, they are considered addressed through the appropriate process and may be taken out of the IDN guidelines (a potential way of closing it).

Comment: Once it’s implemented, whether the GNSO or Board initiates the process and seeks that WG - the WG will then have to work through it to create the Recommendations to go back to the usual Council and Board to address them (the logical extension of how the team are looking at making the Recs.)

Clarification Question: When you say “deferred” is it permanent?

Answer: No, it’s pending re: EPDP addressing

It’s a process question. The Council goes back to the Board to say these are being considered by the EPDP and it’s up to the Board to decide what they’ll do with it.

Guideline 11

Procedural Question: As the team reviews these guidelines, some may be deferred, but do they ultimately wrap into what this group produces? Or if we reaffirm IDN 4.0 guidelines, does that language get put in?

Answer: Both options work, but this group has to decide what they want to recommend back. Do they keep the guideline as is, reword it, or take it out completely.

Possible Way Forward: As it’s the same as the same-entity principle, they can have a recommendation (non-policy) that the IDN Guideline be updated to remove.

Comment: The team has to be careful because these also apply to CCs therefore it would impact them as well.

If it’s going to be reworded, a new process needs to be put in place - if the GNSO policy already superseded it for existing or new gTLDs, the policy won’t have a replacement for CCNSO.

Question: In ccPDP4, they explicitly stated they won’t touch on second level recommendations (outside of their remit). Would the implementation guideline then have any impact on their work?

Question: Can we maybe complement our recommendation C1 and C2 with another that says that the IDN Implementation Guideline v.4.11 should take into consideration our C1 and C2 during implementation.

• We don’t take any implementation guidelines out of the v.4 policy but add another recommendation for them to consider our recommendations.

Summary: All paths presented currently seem problematic, and the team will need to come back to this topic.

Guideline 12

[Staff providing an overview]

Question to Group: Is this a policy question that should be addressed or is down to implementation detail and it’s up to registries to address it? (as the language in the guidelines say: “must have mechanism”)

Context: ICANN receives requests that certain variant labels should be automatically activated (for example if they apply for simplified chinese, the traditional label should be activated even without a request.) The org hasn't had any guidance on it in the past so they haven’t acted on all requests and policy states they can only act on it from a specific request.

• This guideline allows for that provision and it’s not discussed by the IDN EPDP.
• This recommendation was put in because it allows for potential activation automatically.
• There would need to be feedback from the group because the GNSO suggested this should be taken up by the EPDP in the response back to this guideline addressing all of the pieces noted above.

Comment: EPDP team has discussed this recommendation thoroughly and their recommendation should override this existing guideline.

Comment: The decision of whether automatic variants are supported and whether how many/the limit should be left to the registry to decide. The DNS for this is already run by the registries and they should think about what they are doing, and there shouldn’t be restrictions on the way they want to run the business.

Important to Note: There is existing SSAC advice on this in the context of TLDs - that says that variants being activated should be minimized to prevent management issues. They explicitly talk about permutation issues at the second level and across variants at the top level. (Without any new guidance), the default would be to minimize variants without automatic activation.

• If that position needs to be overwritten, this WG really needs to say something about it.

Question: To what extent was the SSAC advice part of the discussion around the development of this guideline?

Answer: That is the overall guideline, and the idea was that if the Chinese community wants automatic activation, they will discuss it at the Chinese community level to come up with a recommendation on the minimum.

The limit will always be a challenge re: this guideline.

Idea: Maybe the team doesn't recommend a universal limit but makes a recommendation that says if a registry wants to have automatic variant activation, they have to set a limit of their choosing (noted explicitly in the contract).

Question: If this is a missing piece in what we’ve discussed, then does the team want to have a policy recommendation that is consistent with this but gives discretion to the RO to decide what the limit is and whether or not it has automatic activation?

ACTION: Staff should add an implementation guidance to state that to a pre-existing recommendation we’ve drafted or can develop a new recommendation. Registries have their discretion to implement policies; however, they should take into consideration the SSAC guidance.

• Staff can reference SSAC 060 and leave it to the registries to implement themselves.

Guideline 13

This one is tied to IDN Harmonization and may be difficult to discuss now - can be deferred to when the team discusses that item - (people agree)

Guideline 18

[Staff providing overview]

Question: Do they include grandfathered processes or is it completely different?

Answer: There is a guideline on transitioning. Those are the types of transitional exceptions and they should make it public and part of the policy.

Follow-Up Question: Then should we put a timeline to this? The same-entity grandfathering, we said that those existing domains and variants that do not have the same-entity may exist as long as the registrants (have to be at least 2) want to use them. Or is it sufficient to say, without explicit dates and grandfathering remains until it’s gone?

Answer: It can be triggered by an event and not a time - the idea is to make it available for people to see.

Comment:

• There are registries that do not publish all of these details - and when a lot of the recommendations leave it up to the registry to implement, there should then be a recommendation to ask the registries to publish their policies (to their discretion).
• The WG may be able to add Guideline 18 back and it will automatically apply to ccTLDs, as many others may not be in the position to be added back in as easily as this one.

Potential Path Forward:

• Maybe it’s worth considering developing some Implementation Guidance to suggest to the registries that they should publish these policies to reflect the implementation of the recommendations and in particular the same-entity principle and how they manage IDN tables.

There’s a gap here - when our recommendations don’t map exactly with what’s in the guideline. Does the team want to affirm it?

When there is a gap, maybe staff can make a note that the recommendations have covered this part of Recommendation 18, but it does not address specific parts.

The team should recognize the fact that this language is 5-6 years old and it’s not exactly aligned with what is currently being discussed. Supports the proposal to put forth implementation guidance on this.

Discussions In chat: there is back and forth about 18b as it links to Guideline 6 (which was also deferred), the rest is in 4.1. Maybe E can be removed and discussions move forward.

ACTION: Staff will work with leadership to develop some language to address this.

Session 8

ACTION ITEMS

• The RySG will deliberate and get feedback on harmonization / variant tables

NOTES

Starting with an ice breaker, the chair passed it to staff to discuss IDN table harmonization. 

P2 Prelim Recommendation 1 states that IDN tables for a given gTLD and its variant gTLDs must be harmonized. The goal of the harmonization is to create consistent variant sets. 

There was a question why the IDN IG V4.0 Guideline 12 only affects some TLDs and not all. The answer was that the process was focused on variants and spread from there

There are two parts of the guidelines, per staff. One is the process and the other is the data.

Examples were provided with a pair of scripts, the code points behind the characters, and then the # of overall code points available for registrations.

Some registries that, for example, provide only Latin script TLDs decide to then offer Cyrillic script, it would be possible that they would accidentally offer the same glyph with different code points to potential applicants. 

Within scripts there are also potential conflicts. Katakana and Hiragana, for example, have similar or equivalent looking glyphs with different code points. The risks for phishing or spam using the same glyphs with different code points are a problem area of note.

Through the IDN guidelines and now the EPDP, there is a concerted effort to tackle this issue.

Harmonizing within the script is important to resolve issues across and within scripts. The relevant script communities have verified the materials for conflict and the idea behind the guidelines need to be extended to variant TLDs. 

The tables are not consistent in their current form, per staff responding to a question from a team member. The team member asked if the staff were suggesting making registries use defined code points going forward? 

The chair had mentioned that in the past this was at the will of the registries to operationalize, the proposal is for this to become compulsory for registries. 

For clarity, a team member said, this is not used by registries. The presentation for ICANN / IANA / Registrars is different from internal use. This may cause registries to invest large sums of money for internal purposes for what they view as little benefit. This is the process for how registries implement their procedures.

The staff suggestion is that if someone registers “APPLE.TLD” another party shouldn't be able to create “APPLE.TLD” in cyrillic and to be used for phishing. Making this necessary for registries might be able to help with these issues. 

Given the discussions earlier, there needs to be a balance between the costs and the costs of abuse in the DNS that can be born from not taking action. 

A team member said it's difficult to say what registries do, and the mechanism for differentiating characters and code points. Using yesterday’s registrar WHOIS page, there is a way certain registrars go about implementing this, but it is undefined at the registry level.

A question was posed from staff if the registries should look at the community work on variant definitions and then consider it for harmonization or is this something the group would be against recommending?

There was previous discussion on this current presentation, but the chair is not sure if there was approval then and probably won’t succeed as a hard requirement, but may be a soft recommendation. 

It was noted that if this was a suggestion it would receive more support than if it was mandatory. Difference between recommendation and obligation. 

Also, what is the role of the registries vs the script community?

There was a team member asking about mitigating vs eliminating DNS abuse. A different team member said that it will never be eliminated, but this presentation and proposal is about minimizing the risks of DNS abuse.

A member of Staff mentioned that outside of the Latin Generation Panel (GP), there was consensus on variants but the Latin GP eventually caught up to the other scripts. 

Defining variants took a long time and a lot of people. Reusing the GP data is a reasonable argument due to the due diligence and intelligence that went into creating this data. 

It was supported by a team member to force registries to consider this. Might not mean they go with it, but they should consider it. Maybe the team should prescribe certain parts and not others. At the end of the day, standardization will be a benefit to the system. The answer could vary. 

Could this be an implementation guidance? It is possible per a team member.

A team member said that consistency is not enough for harmonization. 

ACTION ITEM: The RySG will deliberate and get feedback on harmonization / variant tables.

The suggestion from staff is that if exceptions have to be made from the defined input from the generation panels then that is fine, but the original state is that they should implement the rule before doing so.

There are concerns that were raised with the potential publication date of the hypothetical policy regarding harmonization. Due to the 18 month turn around after the policy is adopted, there shouldn't be a concern, which the team member agreed with.

Per a comment in chat: “Root zone LGR is already implemented at the top-level for gTLDsl. This discussion is to consider the data for second level registrations.” 

A different comment in chat said: “the LGR panel has no responsibility for their actions, even if they issue something non implementable or questionable”. This topic was expanded upon “for the script communities are not such a standing community as far as I understand it, for some who have already completed their work it may be difficult to reconstitute them to ask them for additional feedback”

There was a request to take a step back and look at a potential output.

The chair suggested that a hard requirement should be replaced by a soft requirement to go off of the LGR. There is also a possibility to recommend that this should be studied more at the second level. 

There is potentially a problem with DNS abuse, but little evidence at the time of this happening. Maybe just recommend further work should be conducted once variants are introduced. This could be a middle ground for the team.

Overall there is going to be a push for variants at the top level. The corresponding second level will also add complexities. Walking into this without having everything squared away might be a bad idea, including not having harmonization finalized. There are various options to consider but might take a while to figure out.

The chair asked for a dataset to visualize how registries currently deal with these subjects. Do registries tackle harmonization? If so, how do they do it?

For clarity, a team member said, if a registry only offers one script (even with variants) they shouldn’t have to make checks of the similarity of the script to potential conflicts. This would increase cost and complexity where it is not needed. 

Staff responded “For registries only offering a single script/language IDN table, harmonization is not needed.” 

There may be a problem with requiring harmonization but not defining it, per a team member. There needs to be a way for registries to check if their IDN tables are harmonized. If the team requires registries to make code points variants, then the policy needs to define which code points need to be variants and at the moment the only consistent possibility is to say everything in the RZ LGR that is a variant, if you use it, it needs to be considered a variant too. Otherwise it is too subjective.

DAY 3

Session 9

ACTION ITEMS

• The Contracted Parties and ICANN org will discuss how to include the definition of harmonization for registries to check if their tables are harmonized to the correct level.

NOTES

Day 2 Recap 

• WHOIS RDAP: primary and variant TLD needs to be captured on the IANA website. 
• Process to update guidelines: improve the current process and adopt some of the practice in ePDP including the check-point in the process to prevent any surprises. 
• Gap in the deferred IG4. - staff to identify the gap and to draft strawman how to inform back to the board. 
• IDN Tables must be harmonized and for the reference LGR those must be considered (soft requirement). 
• RySG will try to get data on the current level of harmonization implementation. Informally, there are not many. Feedback from RySG would take two weeks at least. 
• How registries check or know if their tables are harmonized enough will be discussed in the IRT. The definition should be clear. E.g. if there is only one script under a TLD, there is no need to consider the cross script variant. 
• Action: Ry, Rr, ICANN org to discuss how to include the definition of harmonization.

Preliminary Recommendation 5: 

Question: In the rationale, should the word ‘delete’ be changed to ‘deactivate’? 

• This is needed so the primary domain name still exists, though deactivated, and the variant set can be calculated.

• The change of the source domain is possible, but the ‘source/primary’ domain needs to always be identified, so that the variant set can be calculated. 
• There could be some nuance in implementation of the two models; EPP create vs EPP Update.

Conclusion: 

• Change deletion to deactivation

Question: If the language is updated from ‘deletion’ to ‘deactivate’ would the text in the “Pending Deletion” need to be updated? 

• There may be two different models and needs two mechanisms to handle. 
• Register all the primary and all labels in the variant set in the zone file. 
• Using the ‘index’ variant, which is one label representing the variant set. Only one representative label is registered in the zone file. What is the source, what is the variant is managed separately by the RO internal system, not in the zone file. 

• The suggested update to the text In Pending Deletion section: 
• “The EPDP Team agreed not to prescribe any policy recommendation pertaining to the deletion deactivation of source domain names but leave it to the discretion of registry operators and registrars in accordance with their policies and practices. The EPDP Team understood that registry operators would not allow a situation where the deletionchange of the source domain name, if permitted, renders its activated variant domain name(s) “blocked” due to compliance requirement of IDN Table implementation. “ 
• Is it required that all activated variants are registered? 
• Yes, if using the EPP UPDATE 
• No, If the EPP update method is used, only one record will be registered. 

Session 10

ACTION ITEMS

• For Variant Domain Name, Staff needs to adjust text regarding “registered in different ways”, which implies different mechanisms.

NOTES

Starting with an ice breaker!

Tabling discussion about pending delete, and what the proper text might be.

Decision to change gears and review the glossary instead: https://docs.google.com/document/d/1NaDttdqEdrNeWPxZVWm2JA565zN3beFx7ZGbYlQ-lq4/edit#heading=h.8kop0vqgn90n. Plan is to go through the entire list, but focus on key ones where there may be additional clarity needed, which includes at least Activate and Allocatable. 

Question of whether Allocated is needed. Question from members whether there is any difference with Activate. Additional question about difference between registered, activated, and allocated.

Register is related to registry to create an object via an EPP command. Activate is in relation to variants and means that the variant is now usable (which could also mean it is Registered). Question of whether or not Activate should explicitly say that the domain is in the DNS. Note that Redemption and Pending Deletion are not active in DNS, so the text is potentially not accurate or consistent.

Allocatable is one of two technical terms in reference to variants, the other being Blocked.

Helpful to think of the necessary status from an end-user perspective. The elements that they will care about is understanding Allocatable and Blocked variants, and which are Activated.

Suggestion that a visual of the domain name life cycle may be needed, including when it is in the DNS or not.

For Allocatable, suggestion to include reference to LGR RFC, since this is the origins of the term. Same suggestion for Canonical.

In the instance where full definitions are reproduced, it might make sense to either provide a reference to the referenced definition, reproduce in full but make sure it’s clear that the text is verbatim from another source, or to provide a summary and direct the reader elsewhere to learn more.

Pointed out that domain name lifecycle may go through all five main stages, but not all will go through all stages.

For Grandfathered, suggestion to swap “old” with “previous”. Suggestion that the latter part of the text is not a general definition of Grandfathered, but specific to the IDNs EPDP Team’s deliberations. Agreement to move text to the right-hand column.

Suggestion for IDN Table second-level domain names, it might be more accurate to reference labels. Suggestion to again move some of the details to the right-hand column.

Note that for the Applicant Guidebook, the term String is being used. Might be useful to note these terms are interchangeable in some contexts. 

For Registrant and Registrar, suggestion to move some of the detailed text to additional notes.

Question about whether or not some of the definitions need amendment to take into account new relationships from managing variants. The term Registrar can point to the relevant recommendation.

Registry Operator definition seems to refer to the registry database. Can rename this term Registry Database and add an additional term for Registry Operator, referencing the RA.

For the third line, suggestion to swap “contact” with “registry”. Swap “admin, tech, or registrant” with “domain contact or host”. Also a suggestion to move some details to the right-hand column.

For RZ-LGR, suggestion to avoid reference to a specific version. Can ensure the reference is up to date, or just strike.

For Same Entity, suggestion to remove reference to Phase 2 since this is the persistent concept. Here again, the team may want to move definitional text to the right-hand column.

For Source Domain Name, more discussion needed for definition, especially as it references the variant domain set. May want to reference primary domain name, since it’s a related term. Can also consider adding “primary domain name” in parentheses for the term. However, this team did not use primary in its text, so probably better to use in the right-hand column. May want to explain why “source” was used as opposed to “primary” at the top level.

Question whether the source domain name must be the same for the variant domain name set under each variant gTLD. It seems that this is not being prescribed. 

Should ensure that the source domain name recommendation mentions “registered”. Recommendation 5 may benefit from this change. The recommendation should be worded as under a given gTLD “and for each of its gTLD variants”. A member from ALAC to suggest text.

For Variant Domain Name, need to adjust text regarding “registered in different ways”, which implies different mechanisms. Also concerned about reference to “spelling of words” -  A team member suggested text. Key aspect here is that the generation of these names come from the IDN table. Definition added to chat from a team member: Variant Domain Name: A label generated as a variant of a Primary IDN Label based on a given LGR (or IDN Table and IDN registration rules)

For Variant Domain Set, does this include the top-level? Do they need to be delegated? It might be helpful to differentiate between top-level and second-level Variant Domain Set, or to include a definition of a superset. The Variant Domain Set is inclusive of the top AND second level. Can potentially establish a new term, Variant Label Set, which would be limited to the second-level set, for a given gTLD.

Can IDN tables vary across variant gTLDs? The answer seems to be yes. 

Should a Variant Domain Set include non-delegated gTLDs since, since they do not exist? There will be a need to specify in the context. At the top-level definition, it was limited to delegated variant gTLDs.

Session 11

ACTION ITEMS

• Staff should draw a picture of the life cycle, preferably of the domain set of variants. Without it there may be confusion (different interpretations of where the domain exists.)
• D4.6 should be changed to allocated as it includes the lifecycle stages of redemption, pending delete, where the same-entity principle should be upheld.
• D6.7 should be modified to reflect that it can be allocated as variants that are currently EPP Hold or don’t have name servers (not activated) must still be included in the transfer.

NOTES

[Staff providing overview of what was discussed during previous session (prior to lunch)]

Question: We were discussing two terms (are we going to define both)?

• Variable Label Set
• Variable Domain Set

Answer: The glossary has the entry for Phase 1 (only on the top level) and the doc can re-use what was already explained for the top level with an additional explanation for the second level.

• Staff will re-explain variant domain set as a separate entry
• If staff identifies any other issues, they bring them forward to the group for consideration
• When the team uses variant domain set in our recommendations, it may need to be qualified it if referring to the variant and the variant gTLD that are delegated

Question: Does this also apply for ASCII gTLDs?

Answer: Yes, and potentially at the top-level as well - it could be a variant TLD, (allocated but not locked).

• Strauß is an example and it will have the variant with double ss in latin.

Term: Activate

The definition says to be activated and in pending/pending deletion as long as it’s not deactivated from the DNS; however, it’s ALWAYS deactivated from the DNS. They might have to remove the condition as long as they are not deactivated from the DNS because they contradict each other.

Maybe it can say “a domain name is considered activated regardless of status as long as it’s not deactivated from the DNS.”

• It covers all different statuses as long as it’s not deactivated.

Then the redemption and pending deletion states are lost because in those states it's not in the DNS. There needs to be one term that covers the domain throughout its whole life cycle even if not in the DNS anymore.

Maybe the team wants to use “allocated” instead of “activated” because it does not imply that it’s in the DNS (visible to the outside world).

ACTION: Staff should draw a picture of the life cycle, preferably of the domain set of variants. Without it there may be some confusion due to different opinions of the same term (where it belongs).

• Maybe the contracted parties can point the team in the direction of where a graphic can be found for this.
• If people have existing resources it would be very helpful

The issue is there is a different life cycle than the current one. Staff needs to draw specific areas like “DNS” and an overlapping area called RSS and SRS (the registry system allows that special party which is one entity to have rights to activate).

Will the lifecycle be different for certain registries? (It will be different for both)

If it’s not manually renewed, it expires. At some point during the expiration period, all gTLDs have auto renewal and it always goes to the yellow arrow (see graphic) and never the orange yellow.

There can be a separate entry for allocated and the team can try to explain the meaning of that

When the “additional notes usage” is looked at, it talks about the differentiation between activation vs. registration. What’s the purpose of that? To draw that distinction or to talk about when that variant domain name is active?

Note: The team also has to distinguish between “activate” and “activated.” The difference between registered and variants is that registered always requires an EPP Create Command.) It should always say “variants are activated” independent of the fact that they are registered and created or in another way.

The adjective “activated” it’s the description of a domain being IN the DNS. (Active therefore visible in the DNS)

Comment: There is a difference between registration and activation

When you put them together it could be a source+activated, and a source+deactivated, allocatable+activated, allocatable+activated/not activated, and blocked

• In the five different life cycles of the domain they can be in each of these

Team member in Chat:

Three disposition statuses:

1. source IDN
2. Allocatable IDN Variant
3. Blocked IDN Variant

Two activation status:

1. Activated
2. Deactivated / Not-activated

To a total of 5 possible composite statuses:

1. Source IDN + Activated
2. Source IDN + Deactivated
3. Allocatable IDN Variant + Activated
4. Allocatable IDN Variant + Not-activated/Deactivated
5. Blocked IDN Variant (+ cannot be activated)

Question: Is there anything specific to IDN variants that’s not included here?

Answer: It’s okay the way it currently is and “registration” can also refer to variants, but it does not necessarily need to (depending on policy of registry) but variants may also become active via other means/registration. Registration is always a process of creating a domain name and acquiring it for a certain period of time implying that a registered domain name always has an expiration date (an important property of registration). A variant doesn’t necessarily need a registration (a EPP update command) thus it does not have its own expiration date/lifecycle, etc. (aka properties of a registered domain).

If people believe “registered” is preferred over “registration” then the team can use that terminology.

This will be applicable to the source domain (the first one has to have a source domain to create a variant).

The team hasn't yet decided how a source domain is assigned or determined (it’s left up to the registry/registrar protocol) but it’s most likely the first registered domain that is the source domain. There may be other ways.

Question: What if someone wants to do a defensive registration but doesn't want it available for registration for anyone else. In some ways, I’m registering - is that possible? Does that mean that registration is slightly different than activation?

Answer: Registration and activation are not the same. Registering a domain does not mean a domain after being activated (just means it exists in the SRS and is visible in the WHOIS and is not necessarily added to the DNS). It can be registered defensively.

When it means allocatable variant from allocated variant set, it means the same so it sounds okay

The same-entity principle applies to the activation of future domain registrations and that’s it (sounds simple enough)

Activation is just a broader expression of making the variant available (via registration–one way of activating a variant) but also via an update to the source domain name or other domain.)

Can we just say “withheld for the same registrant” and remove all of that (not talk about activation or allocation) as they can do all of that as they are the same-entity?

Comment: There does not need to be unnecessary details in the recommendations themselves.

Idea: Are “activation” and “activated” necessary or can it be replaced with “allocation” and “allocated?” This includes registration with activation and it also includes the activation of variants via EPP Update Command through registered domains.

• it also covers cases in pending delete and redemption period

Activation is important because it’s part of contracting and personally he does not think allocate can supercede activate (it cannot be the other way around because if the team only says allocate or allocated, then it says nothing about whether it’s activated to the DNS) and both in terms of fees and in terms of processes and whether registries are allowed to activate the name, comes into question.

The fact whether a variant is active or not or whether it’s in the DNS or not is not important for the same-entity principle. Only whether it’s allocated or not is important.

Even if activated is replaced with allocated,a definition and relationship to allocated are needed.

The “same entity” principle applies to the allocation of future variant domain names. This means that all allocatable variant domain names from a variant domain set must be withheld only to the same registrant at the same sponsoring registrar.

C24

• Activated covers both options depending on the mechanism the registry is using.

Question: Why are we grandfathering domain names that are not in the DNS? Grandfathering is something we don’t like but need to have so why do we need it in the DNS?

Answer: It’s recognition that there are currently domain names in the DNS and because of grandfathering nothing can happen to them.

Being in DNS is not necessary for registration - a domain can be registered, not use a name server and be in the DNS.

Question: The situation with grandfathering is that you have two registrants (one of them having some of the variants, and some having the primary and another variant) with the ultimate goal to remove this situation. Why would you grandfather it to be put into the DNS in the future?

Answer :Grandfathering is to protect the interests of existing registrars.

There’s a sub-question here of “if the registration has been done but has not been activated and is not in the DNS” should it be grandfathered? It probably shouldn’t be.

Comment: The team doesn't want the set of grandfathered domains to increase. If there are grandfathered domains with variants that aren’t currently allocated, they won’t let them be allocated until the grandfathering process is over so new domains aren’t included in the grandfathering process.

D4.6

ACTION: It should be changed to allocated as it includes the lifecycle stages of redemption, pending delete, where the same-entity principle should be upheld.

D6.7

ACTION: Again, here it should be allocated as variants that are currently EPP Hold or don’t have name servers (not activated) must still be included in the transfer.

Terminology is not perfect yet but overall understanding has improved based on discussions today

Staff  can maybe create a graphic to visualize the life cycle that a team member created (The participant sent Staff a powerpoint with information)

Progress is about 99% done (want to make sure to note pending deletion for further discussion)

Comment: The policy doesn't need special comments for pending delete (it can mention that in pending delete, the domain is still allocated, therefore everything that is valid for allocated variants also apply to these).

Question: Do registries/registrars have any tutorial programs that take somebody through the registration of the domain name? Something more tangible for us to look at and help us understand the processes and how they may apply to variants.

Next Steps (post-workshop):

• Staff to develop draft text, will review the notes and fine-tune some recommendations
• Strawperson example needs to be developed and shared
• Review glossary once more and update the rationale based on discussions
• When does the team want to resume calls? (Presumption is sometime mid-January)
• First call back will be influenced by whether or not there is draft text to review or if the harmonization piece is ready.

Not anticipating meeting in San Juan. Staff may request meeting space, but there might not be a need to meet F2F.

• What’s our timing for getting the Phase 2 Initial Report out for Public Comment? (Staff will be thinking about this - maybe by the end of February?)
• In our plan there was a timeline of April

Question: When are we supposed to take these recs back to our constituencies to get feedback? During public comment?

Answer: When there is text to consider is usually when participants take it back to their groups for feedback

• If there are any disagreements among the team, attempts will be made to  to resolve them prior to putting it out for public comment