2023-06-01 IDNs EPDP - Meeting #84

Notes/ Action Items

Notes and Action Items - IDNs EPDP Call – 1 June 2023

Action Items

Action Item 1: Ry and Rr members to the EPDP Team take the question about verifying same entity to the CPH TechOps Group. Also consider implications of resellers.

Action Item 2: Staff to check with EPDP Team to see who will attend ICANN77 in person.

Notes

Welcome and Chair Updates

• Public comment close date for Phase 1 Initial Report extended until 19 June.
• Working on the agendas for the 4 sessions at ICANN77. A little challenging to figure out agenda for a good reason: the Team has made more progress than expected. The sessions will be revolve around Phase 2 though.
• Leadership team reached out to groups to confirm or update their membership appointments. Still awaiting input from the RrSG, NCSG, and IPC.

Recap of Previous Discussions and Continued Deliberations: C1, C2

• Slide 4: Reminder of what C1 and C2 are about
• Slide 5: Summary of deliberations
  • agreement to extend the “same entity” requirement to existing second-level labels
  • “same entity” is defined by the registrant
  • Second-level variant labels may only be activated if they are registered to the same registrant (question: of the canonical name?)
  • Grandfather existing second-level variant labels if they are already registered to different registrants and allow them to continue to persist as registered.
• Diverging opinions regarding variant label activation in grandfathering scenario:
  • Opinion 1: Disallow further activation
  • Opinion 2: Allow further activation
• Clarification question about who would enforce (registry or registrar) the same-entity requirement. This was not discussed yet, only agreed on the principle of same entity. Definitely need to consider this question.
• There may be further questions about what grandfathering really means. One question is of course re: options 1 and 2, whether to disallow or allow further variants to be registered if there is already a grandfathering situation. An argument for allowing is an interpretation of whether or not allowing additional variants violates the same entity policy? An additional argument is that it can negatively impact the existing registrants in the grandfathering situation.
• May help to consider motivations for same entity concept. If variants go to two different registrants, it can cause confusion since the variants are supposed to be the “same”. It can cause user end-user confusion and potentially be leveraged for malicious reasons. Allowing additional variants likely increases these risks.
• Noted that there is a lack of data about the scope of grandfathering that may be needed. It is likely that it is not a serious problem or else it would have probably surfaced by now.
• Taking into account the end goal of the same entity principle being defined as the registrant, registries and registrars will need to make modifications to their systems to manage statuses and life cycle of the domains and variants. It will be difficult to manage edge cases like managing variants going to registrants in a grandfathering issue. This would support the principle of minimizing exceptions over time.
• Any time the principle of same entity is violated it can create user confusion. Grandfathering is an exception and not ideal. Getting rid of the exception process sooner rather than later is sensible. Support for disallowing.
• Question about what happens if there is competition for allocatable variants when grandfathered. Calls into question who would adjudicate the rights.
• Question about registration process and any validation checks that take place. When a registrant wants to register a domain name, they go to a registrar, which sends a domain check command to the registry, the registry responds whether domains is available or not, then registrar registers the domain if available.
• Because of the policy development lifecycle, there can be more grandfathering situations created between now and the policy effective date.
• Question about whether there are any issues with renewals with grandfathering. Renewals, and auto-renewal, should not be a problem and should be allowed. The domains should persist until they are actively deleted, which would eliminate the grandfathering situation. No objections to allow renewals.
• Inspired by the renewals discussion, it seems that inter-registrar transfers should also be possible. There are additional charter questions that specifically discuss the domain name life cycle. We might not need to specifically call out every situation as it will quickly become complicated. The next set of charter questions are in fact on the topic of the domain name life cycle.
• There is also an existing requirement that variants should be managed by the same registrar. Allowing transfers when grandfathering, it may break the same registrar requirement (e.g., where one domain name is transferred and one remains).
• Knowing the size of the problem is not necessarily important to Option 1 and 2, but still good to know. However, data is difficult to obtain.To the point about end-user confusion, if they are already being using concurrently, it is apparently happening without major issue.
• In a grandfathering situation, it’s unclear which is primary/canonical. The new policy would not create variants – those are determined by the RO’s IDN tables, at the point of registration. It seems that the canonical name is irrelevant since there would not be additional registrations allowed in the grandfathering situation.
• Slide 7: examples for activating additional variants when grandfathering. Answer already determined: no additional variants.

Discussion of ROID: C3, C3a

• Slide 11: Reviewing charter questions C3, C3a. This question is about the appropriate mechanism to identify the same entity. The Staff Paper suggested that the ROID could be a reasonable mechanism, but noted that there may be challenges. C3a is conditional upon agreeing that the ROID is the right mechanism.
• Slide 12: The Staff Paper discussed 4 options:
  • Using ROID
  • Having all registrant fields be the same
  • Having a core subset of registrant fields to be the same
  • Cryptographic probe to ensure the same registrant. The Staff Paper itself itself says that this approach is likely impractical.
• The Staff Paper recommends the ROID.
• Slide 13 – further details on what the ROID is, how it is created, what it looks like, how it is used, and how it is stored.
• Clarification: At the time the contact is created, it does not have a property like admin/tech/registrant. So, the ROID is independent of that property.
• Slide 14: Benefits and drawbacks of using ROIDs (information coming partially from Staff Paper).
• The charter question is specifically about the ROID, but this seems like it may be an implementation detail.
• ROIDs are unique per object, but sometimes they are reused. Concerns about privacy laws. Only -EXAMPLE is in the IANA repository. There may be multiple ROIDs for a single registrant in a given registrar. The registrar is in the best position to validate a registrant as it owns the relationship.
• Registries under GDPR can determine to not publish the ROID.
• There is no policy that requires that variants must be activated by the same registrar.
• Putting ROID aside, is there a single mechanism that can used to ensure same entity? Or should it be left to Registries and Registrars.
• The CPH TechOps has discussed whether ROID is the right option. Has also discussed other options that could serve as a single solution. There are of course benefits of having an industry standard, but there are costs involved. A different question for this Team could be about which party is in the best position to enforce the requirement.
• The first point of contact is the registrar, where the education of the registrant can first occur. If there are concerns about privacy, a hash to obscure the details, could be used to create a unique ID.
• Disagreement that the registrar validate whether the registrant is the same. This validation check is needed when domains are going to be variants, which is responsible for identifying variants. If the registrar were to need to validate, it would need to use the ROID.
• Taking into account resellers, the registrar would need to validate. The registry would not be able to determine the relationship.
• Slide 15: Anecdote of current practice: To check same registrant, uses contact handle, or basically ROID.
• If the Team were to identify the ROID as the best option, would this be the responsibility of the registry or the registrar? It seems like it would be the responsibility of both parties. For registrars, it would mean having to reuse existing contact object IDs.
• If data structure is changed, it would affect existing records. Need to consider data transfers between registry and registrars in the context of RDS.
• Suggestion to focus on the policy, not the mechanism, as well as the party that is contractually responsible for enforcing.
• The answer to the charter question could be that the ROID is indeed a reasonable mechanism, but not enforce ROID as the mechanism for the contracted parties.
• Raising the question again, who is responsible (registry or registrar) for ensuring same entity requirements? Unclear, some are saying that registrars hold the relationship, and others are saying registries because they manage their LGR.
• Suggestion that registry enforces same registrar; registrar enforces same registrant.
• Registry has no contact with the registrant and has no means of verifying the contact details. Disagreement, registries can be 100% certain by verifying by using the ROID.
• SRS system may assign a ROID after creation which may make it difficult to use the ROID to identify same entity.
• Registries that perform KYC should be in a better position to verify same entity. Understanding the legal entity should not be important. It just needs to be the same registrant. Section 7 of the registration data policy does not include ROID as part of the minimum data set.
• Suggestion to take the topic back to the CPH TechOps group since the Rys and Rrs need to discuss the technical details of how to manage the process.

Action Item 1: Ry and Rr members to the EPDP Team take the question about verifying same entity to the CPH TechOps Group. Also consider implications of resellers.

• Reminder that resellers need to be considered.
• Hopefully there will be information from CPH TechOps to deliberate at ICANN77.
• Reminder that this might in the end be an implementation detail. Guidance will still be beneficial.

AOB

• No call next week in preparation for ICANN77. Leadership team will be working to put forward an agenda for ICANN77.

Action Item 2: Staff to check with EPDP Team to see who will attend ICANN77 in person.