Page History

...

1. Roll Call and SOI Updates 
2. Welcome and Chair Updates 
3. Conclude deliberation on D4, C4a, D6, D7: Variant Label Behavior in Domain Name Lifecycle
4. AOB

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

Notes:

Welcome and Chair Updates

• None

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

Question 3

• Picking up on three. It seems that there is agreement that for Transfers, they should travel as a set to the new registrar.
• Question about whether the outcome is relative to voluntary and involuntary transfers. Language needs to account for both.

Question 4

• For Lock, must they all be Locked at the same time and for the same duration. Would update, transfer, or deletion be allowed?
• May need to consider more use cases whether a lock on one variant would apply to set. For instance, court order might apply to just a single domain in the set. If the entire set is locked, is that overreach? Need to identify the various use cases.
• If one is Locked, the others would still resolve. The user may not be aware of the change in status. Might need to consider a notification system.
• It might not need to be decided as it could be dependent upon the registry’s policies.
• Unclear which variant is primary, especially with grandfathering. There could be simultaneous registrations by different registrants for the variants of each other. Might need to review order of registration process. Would a registry need to have a database of all combinations?
• It might make sense to make policy for things like Transfers, where they must travel as a set to the registrar. However, where it is not required to operate as a set, it might not make sense to set policy.
• Need to consider whether the set of variants need to behave the same way. The IDNs EPDP could potentially contradict the SubPro rec. If presumably domains may behave differently, this could be a reason that they do not always move as a set.
• Need to think about when a Lock happens, does it create a risk by only having it affect a single variant in the set?
• Lock may be a result of nefarious actions by outside parties. Therefore, may not be good to Lock all at once.
• Maybe helpful to think through if Lock does not apply to full set, what happens. If there are cases it does not make sense to Lock all at once, this would suggest that forcing Lock on all at once is problematic. “Same entity” for transfer seems to be the most important factor.
• Talked about updates yesterday at the registrant level, where it could be across the set. Or not. Reinforces that Transfer is the most important part for keeping as a set.
• Same entity isn’t about same behavior over the set, it’s about ownership/registrar.
• This would make it discretionary to the registry/registrar relationship and rules.
• Regarding update, agreement was that so long as same entity principle is maintained, asynchronous updates are allowed.

Question 5

• No explicit definition, but from EPP, it means clientHold or clientTransferProhibited.
• Likely a similar outcome here to question 4.
• There are cases where a registry may want to suspend all variants at once, but it might be because of their business case.
• If there is inaccurate RDS info, it may make it harder to determine if the set is unified.
• For example, a court order forces the transfer of ownership, the entire set must go. Caveat: unless there is a grandfathering case.

Expiration

• If a domain goes into expiration, nothing changes. So therefore, nothing seems to need to be done here.
• For auctions, does the same entity principle apply? It seems that the transfer policy for same entity would apply/control.

Redemption

• Uncommon to get to this stage, but asking about impact of one variant affecting all.

Pending Deletion

• Same outcome seems to apply here.
• Does the answer to these questions vary if it’s based on the base domain versus the variants?
• Maybe better to consider it as the source domain name. However, it doesn’t seem as impactful at the second-level.
• In summary, 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.
• Legally, how is the variant set referred to? It is unique to the IDN variant tables of the registry operator. In principle, it should be the same - need to be careful with the language.
• Question: Seems to be agreement that there should be a source/applied-for domain. Can there be an agreed upon change to the source? Should this be up to the registry? What is the example of where this would be meaningful? Use case is that a registrant doesn’t want to use the primary anymore.
• Registries may put domains into a status as allocated and blocked. This could be useful for existing registrations where variants may not have been properly accounted for. By switching the primary, it might allow for allocatable variants.
• It seems that policy does not need to be issued if it must be solved by the RO (in their best business interest).
• Question from yesterday: Registering at one registrar and then trying to register at a different registrar. Should that be allowed? Should be decided by the WG.
• Very difficult for different registrars to ensure same entity.
• From an operational point of view, it doesn’t make sense to have different registrars. Shouldn’t allow registration at different registrars.
• Current language requires that same sponsoring language, so this would be consistent with current practice. Maybe useful to draft language to make this explicit.
• Since top-level explicitly calls for same RSP, useful to also have at the second-level.
• Clarification that in the process of transfer, deletion is possible for some. In this case, the remaining active domains would need to be transferred to the same registrar.

Grandfathered domains:

• Caveat, need to work on definition but basic understanding is in respect of already registered domain names up to policy effective date.
• For grandfathered domains, can they be renewed? Assumption and previous indications is yes, but cannot register new variants. If renewal is not allowed, it’s not really grandfathering.
• For inter-registrar transfer allowed? Can registrant information be updated?
• Suggestion that if at different registrars, they should only be allowed to be moved to a single registrar, to simplify things.
• To disallow transfer would restrict registrants movement. Grandfathered domains should be considered as independent domains,
• Question: if it’s at different registrars, only the registry can identify same entity. The registry can track the journey of the domains through the life cycle. There are still discussions in the Tech Ops group - shared responsibility for registries and registrars.
• There must already be existing rules at the registry level for variants.
• Do we need an obligation for registries to manage the variant life-cycle?
• In general, do not want to create more fragmentation. For 3 variants owned by 2 registrants, shouldn’t allow it to become 3 registrants. Or 3 registrars.
• The same-entity requirement more generally may capture the life-cycle aspects. But may be worthwhile to introduce implementation guidance.
• Should we simplify or apply limitations for grandfathered domains. So it makes it easier to manage. The general concept should be to avoid making the grandfathering issue worse.
• But at the same time, shouldn’t impinge on their rights to manage their grandfathered domains as they need to. The goal, of not making it worse, seems to be managed by not allowing further variants.
• Another reason to not disallow transfers is because courts can require transfer to another registrar.
• Summary is that existing rules apply for grandfathered domains.
• For change of registrant, should this also be allowed? This could make the grandfathering issue worse.
• Could be that x and y, if owned by a single registrant, they could be required to move as a set, so as to not make the number of registrants worse.
• Need to allow cases where registrant dies for instance, or other cases where the domains need to change hands.
• The preference is to try and reduce the cases of grandfathering over time.
• May need to identify what the trigger is for the end of grandfathering.
• Grandfathering is made more difficult if there is no primary.
• Question: in practice, what is the primary string? Is it first registered?
• When do we get to a situation where the grandfathering expires? Is it justifiable to make their options more limited?
• The practical end of grandfathering is when there is one registrar/one registrar.
• It will be easier to identify gaps once the recommendation language is drafted.
• Wish we had data, but likelihood is very low. Limited by offering IDNs, variants, and having the sponsoring registrar allow registrations to different registrants.
• For identifying the primary, it may not just be based on date. In some cases, it may be dependent upon the registrant’s use case (e.g., Persian versus Arabic). That could impact disposition values.
• However, the use case is that Persian and Arabic strings could be registered. Once the grandfathering issue is resolved and the controlling registrant owns both, the registrant might not want the earliest string to serve as the primary.
• There was a question about a primary string in a grandfathering situation. Use case above demonstrates why it might matter. It could simply mean that the registrant is allowed to choose the primary. And perhaps the registry, in consultation with the registrant, can determine (absent policy).