2023-10-21 ICANN78 Session 2 IDNs EPDP

SESSION 2 ACTION ITEMS

• Develop a response to this charter question. There will not be a recommendation to prescribe a mechanism.
• Consider getting data about usage of ROID, for inclusion in rationale.

SESSION 2 NOTES

• For resellers, this question is likely relevant for the next part of our conversation.
• RAA already has provisions about responsibilities of registrars vis a vis their resellers. 
• Question about who is maintaining the RDDS information and how to enforce the same entity requirements.
• There are two instances of the RDDS information - at the registry and registrar level, with potentially different levels of data.
• How to enforce same entity requirements when the registration data is that of the registering party, not necessarily the registrant. The true registrant information is masked.
• For privacy proxy and for masked registration data, the responsibility resides with the registrar to enforce.
• Slide 15: Refresher on ROID, which C3 suggested as the mechanism to enforce same entity requirements. All registry contacts, including domain objects, have a ROID.
• Under GDPR, using the same ROID helps associate domains to a single entity.
• Slide 16: Refresher on ROID cont., which includes benefits and drawbacks.
• The point about a ROID being assigned after domain creation is not accurate. The ROID is assigned before.
• Slide 17: Where we left off.
  • Question 1: Should ROID be used to identify a registrant as the same entity?
  • ROID may be a reasonable mechanism, but contracted parties cannot be forced to use it
  • Question 2: In, what would be a better mechanism?
  • A joint responsibility between the registry and the registrar to identify the same registrant; The registry enforces the same registrar, and the registrar enforces the same registrant; Registry may have to reuse contact object IDs 
  • Question 3: Any additional info needed for this discussion?
  • ACTION: RySG and RrSG members to take solicit input from CPH TechOps group regarding verifying the same registrant, also taking into consideration implications of resellers
• Slide has summarized CPH TechOps well. Reinforced that ROID is sometimes not available, such as in thin registries. The logic for determining what are variants resides with the registry. The relationship with the registrant resides with the registrar. The CPH TechOps has talked about developing an EPP command to help with managing these transactions.
  • The registry identifies the variants.
  • The registrar ensures that the same entity check has completed.
• ROID currently is not fit for purpose. Could an extended ROID make sense? How to extend same entity across gTLDs?
• Would the registrars be told how to enforce same entity, or do they just need to comply with the requirement? The suggestion from CPH TechOps is yes, enforce the requirement as they see fit.
• Clarification: ROID is often sufficient, but in some cases, it is not. Therefore, it is problematic as a hard requirement.
• EPP creates interoperability. But EPP Extensions can be different across registries.
• Data does not, or cannot, be transferred across registries. ROID does not translate across registries. 
• Could consider noting that the ROID is sensible, in the context of implementation guidance. Should consider the impact of data escrow, or how the relational nature of the set is captured in the registration data.
• Data is escrowed at the registry and the registrar level, separately. All of the registration data will be escrowed.
• Model 3 could have split responsibilities but define the allowable method(s).
• Question about whether the use of ROID is directly linked to thick versus thin registration data.
• Question about how many registries do not use ROID? Which parties would not be able to meet a requirement to use ROID?
• Even if all registries use ROID, registrars are not required to reuse ROID.
• COM, NET, JOBS are thin registries. The registration data policy will transfer the discussion to the minimum data set. ROID is not currently included in that minimum data set.
• Could the recommendation be about the registries and registrars agreeing to develop a mechanism be a way to go? Currently, there are already two ways to establish variant domain names. The CPH desire is to stay at the level of what is to be accomplished, but not prescribe the how.
• There are a lot of moving parts, which makes it hard to recommend a singular way to enforce the same entity requirement. 
• Noted that from a contractual point of view, there is no shared responsibilities. The registries and the registrars are independently responsible for their respective requirements. Registry would enforce same registrar and the registrar would enforce same registrant.
• If we end up with various mechanisms to enforce same entity, will it create consistency issues across the industry (e.g., EPP, data escrow). Within the single gTLD, there will only be a single model. 
• Support to concentrate on just the goal of what is desired to be accomplished and leave details to implementation.
• Concern that the same registrar requirement forces a registrant to use the same registrar for any variant domain names. If a registrant is displeased with a registrar, they are free to move to another registrar.
• It does not seem that models 1 or 2 are the answers. However, the agreement is that the policy recommendation will be about the same registrar and same entity.
• During pre-delegation testing, this may create a more challenging testing environment for evaluation of the RO/RSP. This seems to be out of scope for the IDNs EPDP.
• The question could be different for an RO versus RSP. RO would be asked how and the RSP would be asked to confirm that they can do it.

Action Item: Develop a response to this charter question. There will not be a recommendation to prescribe a mechanism.

Action Item: Consider getting data about usage of ROID, for inclusion in rationale.

Variant Domain Transaction Fees: D5 

• Slide 21: Review of charter question. Similar to Phase 1 charter question.
• Slide 22: Discussion Question: Once a source domain name is registered by a registrant, its allocatable variant domains may be calculated for potential activation. If the registrant decides to activate one or more of its variant domains, should ICANN charge the $0.18 mandatory annual fee for each year of registration, renewal, or transfer of each activated variant domain?
• Noted that registries also pay a fee for <50k, as well as an incremental cost per additional DUMs.
• The answer may be that it depends. There are two models to activate a variant, either use EPP create or EPP update command. The first would incur a fee, the latter would not. 
• Belief that the source and variants should all be treated as registrations, upon activation.
• The variants will not always have the same lifecycle as the primary. How would that affect the billing cycle? This scenario would come from EPP create and would result in separate charges. The two models exist now for registries.
• Suggestion that the registrant usage should potentially dictate the fee structure. Concern about going into these aspects for our discussions.
• There seems to be agreement that the source domain must be first. Currently, some registries choose to treat as create versus others that treat as updates. To dictate a single model now would change the approach for existing registrants.
• However, the existing registrations could be grandfathered if the EPDP wants to recommend a single approach.
• Question about whether the Phase 1 recommendation would be inconsistent if the EPDP elects to keep the status quo (i.e., allow for variable treatment of create or update). The Phase 1 recommendation seems to assume that each variant should be treated as an independent registration.
  • It seems that create would be counted, but update would not. So, no inconsistency is created
• The intent could be inferred. If the usage is similar/interlinked, maybe it’s update? And if the usage is independent, maybe it’s created? Noted that the status quo is not documented, it is just what is done. This EPDP could therefore enshrine the current practices.
• We need to be careful to not infringe on current implementation models since registry models are built upon what is counted as a billable transaction.
• Should our recommendation be at the high level, of what the goal is for the recommendation?