DATE: Thursday, 15 June 2023

TIME: 09:00 - 10:15 EDT

ROOM: Marquis 1/2/3 (GNSO)

Draft Agenda

  1. Roll Call and SOI Updates 
  2. Welcome and Chair Updates
  3. C4, C5, C6, C1, C2: Preliminary Agreement Review 
  4. AOB

Slides: ICANN77 EPDP Team Working Sessions - D4, C4a, D6, D7.pdf


Welcome and Chair Updates

  • Great progress so far. Being able to discuss back-to-back over the course of several days has really been helpful.
  • Reminder to complete survey. Staff will circulate reminder to members.

Action Item: Staff to circulate reminder to complete survey.

  • Questions about F2F days. Will figure out how to identify the best days and help ensure the availability of participants.

Continued deliberation on D4, C4a, D6, D7: Variant Label Behavior in Domain Name Lifecycle

Grandfathered domains:

  • Recap is that definition of grandfathered are domains in a variant set owned by 2 or more registrants, prior to policy effective date. Outstanding question is about whether a primary string needs to be identified for grandfathered names.
  • Whatever the primary string was during grandfathering, should remain the primary domain. Question though is how you identify primary when there are multiple registrants. It could be the primary for whichever registrant ends up as the single entity.
  • In theory, there can be multiple versions of the primary if there are multiple registrants in a single variant set.
  • Yesterday, talked about the concept of primary as better being described as source at the second-label.
  • Maybe do not need to identify a source/primary in a grandfathering situation. The disposition value of the other variants should be the same with starting wherever you start. And since no other variants are allowed until the situation is solved, source is irrelevant.
  • Recap of three recommendations:
    • Identifying source domain name - registrant needs to determine with registrar
    • Same entity requirement maintained throughout life cycle. Registered or withheld. Will include ramifications.
    • Transfer policy - the entire set must move between registrars.
  • However, after grandfathering is done, need to identify which is the source. Could this be solved by deleting then re-adding with “same entity”?
  • A new registrant might not want to delete what might be an active variant in order to adhere to the same entity requirements.
  • Unclear why an applicant who now owns all of the variants would want to delete any of its variants that it now owns. It seems that the grandfathering situation would have already ended at this point.
  • Doesn’t seem like anything needs to be prescribed after grandfathering ends.
  • Regarding potential rec 2, for transfers, can the same entity principle carry forward. For instance, one of the grandfathered registrants owns two variants. Can transfers be allowed, adhering to the same entity principle (for both change of registrant or change of registrar)?
  • Should the two variants owned by the single registrant be able to split ownership? Considering them as individual registrations, it seems they should be allowed to change registrant.
  • For grandfathering, it does not like there is much harm to allowing grandfathering.
  • Grandfathering could happen again in the future even if the RO adopts a new IDN table. The assessment of harm should happen prior to adopting the new table.
  • We have only been talking about grandfathering in the context of prior to the policy effective date.
  • The agreement has been that in grandfathering, the existing rights of the registrants should persist. Is any policy needed, or just allow to be managed by registries/registrars? What harm exists?
  • Questions about whether x, which owns a and b, should be allowed to change registrant. It seems like they should be required to transfer to the same registrar.
  • Difference in understanding - it only comes from an update of a table.
  • In theory, there is the possibility that grandfathering can happen already, based on varying registry practices. Difficult to gather data.
  • To gather data, would need to leverage the tables for each table, since they can be different. It does indeed seem like grandfathering can happen from updated tables.
  • What we are looking at now is that a variant set can have multiple entities. This is what we are trying to protect.
  • Back to the harm question, if registrant x owns a and b, would it not make the grandfathering situation worse by allowing a and b to end up with different registrants or registrars?
  • Seems different because the set doesn’t get bigger.
  • Some registries that do allow for variants already enforce same entity, even if the contract does not require this.
  • While we want to preserve registrant rights, the goal is to try and reduce and eventually eliminate grandfathering. However, it might be a perpetual situation because we should not prevent registries from updating tables.
  • For transfers, something might need to happen because of court decisions or local law. A contracted party will comply with local law first and foremost.
  • Grandfathering cases are likely minimal. Because of the previous point, it might be best to leave it open to the discretion of the contracted parties.
  • It might make sense to consider whether this carveout is necessary going forward, not just for grandfathering. There could be a court order to enforce transfer of just a single variant.
  • Grandfathering means that the requirement has shifted from same registrar only to same registrant. What we are trying to do is to not infringe upon the rights of the registrants. There is some harm to registrants from not being allowed to register additional variants, but that is still the rec this group is looking at (forward). If the goal is to avoid infringing, maybe we should not establish additional rules.
  • For Justine’s example of a court order, hopefully the court understands the situation. Otherwise, it seems like the entire set should move.
  • Data is still desirable, but we shouldn’t have it control our conversations.
  • Enforcing harmonized tables could create new variant relationships and create more “grandfathering” situations, of the second variety.
  • Proposal: prepare draft language and circulate to the group.
  • Last question is about once a grandfathered domain is eventually deleted, should it be “withheld” by the registrar? If so, for whom?
  • Should maybe talk about deletion as the proper milestone. May not need to establish additional rules here. The grandfathering processes would control until the grandfathering situation is removed. The answer is essentially that a registration is blocked anyways.
  • There is no status in systems of withheld. The checks via EPP need to establish that they are available. Practically, it seems that the domain would just be added to the pool and be subject to the regular test that would be applied by registrars.
  • For grandfathering, there can be no activation of variants (or re-activation). However, it seems like it is only one case since as mentioned before, a domain that gets deleted gets added to the available pool.

  • No labels