Hi all,

Please see below for the notes and action items from yesterday’s EPDP IDNs Call #103 on 16 November at 12:00 UTC.

Thank you!

Ariel, Steve, and Dan

ACTION ITEMS

• Leadership and Staff will review the comment from the team member regarding ROID and find new language to convey the option presented for registrars without making it seem like there is a prohibition on their actions.
• The chair asked the team to review this document before the F2F meeting so that language can be finalized.
• Staff will flag areas that are still contentious for review on the mailing list.
• Staff will include time in the workshop to go over RySG discussions on PR6.

NOTES

• Roll Call and SOI Updates (2min)       
• Welcome and Chair Updates (5min)

• The Chair welcomed everyone to the call and provided a reminder to the team of the upcoming Face to Face meeting in Kuala Lumpur.

• Staff reminded the team that a security briefing sheet was sent to them in the past few days for their review. 

• In light of the former Vice Chair stepping down, the Chair nominated Farell Folly to the position of Vice Chair for the remainder of the EPDP.

• At this time there were congratulations sent to Farell and if there are any other thoughts from team members on the appointment, they will send them to the Chair directly.

• Review of Phase 2 Text  (110min)

• Staff started to go through the Phase 2 Preliminary Recommendations. First, it was noted that there is an unresolved comment in Preliminary Recommendation 1. The first updates that were incorporated from previous discussions began in the rationale for PR 1. “Registration” was removed, with “Activated” being used instead. “Consistent” replaced “same”. Edits were included to avoid confusion between Harmonization with the Same Entity Principle. 

• There were no objections to these changes.

• The next changes were located in the C1 EPDP Team Response, with “Activation” once again being added where “Registration” or “Allocation” were present. 

• There were no objections to these changes, but a few team members asked for time to review these updates as there is concern that “allocate” and “activate” are still used interchangeably. 
• In an example for domains at the second level at a registry, the point of control for variant domain names is at the registration level. That is where it is checked for availability and there is no allocation table for the registry. Registries will check for availability and if the registration meets the criteria for the same entity and other ideas, then they will activate the domain name. This may help staff identify where to use allocate vs activate.

• There are three different states for domains and they should not be equivalent per a team member, but they also cautioned there may not need to be a change in the language for the document.

• RDAP and WHOIS queries, there are discussions at the registry level for what needs to be provided to registrars and registrants about what is needed for variant domain name sets. EPP responses are going to need to be modified to include more information. Now that a domain name can have an extended set and the extended set is now available for anybody, then registries need to accommodate a signal so that registrars know what is happening at the transaction level. There are going to be changes in how the contracted parties interact with variant domain names, but these are early conversations. 

• A staff member agreed with that recommendation language may not need to be changed due to qualifiers in the document. 
• The chair commented that they believe the language is acceptable and they should proceed but give everyone a chance to review after this meeting. 

• The word “registration” was replaced with “domain name” as to account for variants possibly not being new registrations, but instead other transactions that can be accounted for by using the phrase domain name in the text. Also of note, were the global change for activation instead of registration and the softening of a recommendation to better capture a nuance in PR 3.

• There were no objections from the team to these changes on page 7.

• On page 9 there were updates to the rationale to better explain the context around the example in the text in a way that enhances the clarity. There were other changes to reflect the suggestions of a team member to add another example for how grandfathered cases factor into this process. 

• There were no objections from the team to these changes. 

• Staff added context of some drawbacks to ROID usage and provided some further updates for clarity

• A team member thanked staff for their comprehensive recap
• One team member in chat posted: “Under C3, I was uncomfortable with the use of the phrase "may not", because it could be read as if it is forbidden". In this text "The Registry Agreement only requires unique-per-object ROID; the same ROID may not be assigned to the same registrant across gTLDs managed by the registry operator, and the registrars may not reuse contact objects for different domain names of the same registrant." I suggest replacing all the "X may not do Y" (which could be misinterpreted as "it is forbidden for X to do Y" with something that better conveys the idea that "X is not required to do Y". For example, "The Registry Agreement only requires unique-per-object ROID; different ROIDs may be assigned to the same registrant across gTLDs managed by the registry operator, and the registrars may use unique contact objects for different domain names of the same registrant." 

• The intention is that the registrar “may do this or may do something different” but the reader could interpret that as a prohibition. It should not be interpreted that way, but it possibly will. 

• This received approval from multiple team members.

• ACTION ITEM: Leadership and Staff will review the comment from the team member regarding ROID and find new language to convey the option presented for registrars without making it seem like there is a prohibition on their actions.

• ACTION ITEM: The chair asked the team to review this document before the F2F meeting so that language can be finalized.

• On page 12 and 13, there were further “global” edits on activate vs allocate and other updates for clarity for D4.

• A few team members requested that on page 12 allocated may fit better over activated. 

• Per another team member, the lifecycle is for registered domains. Before registration it is not applicable. “activated = registered , allocated - has a potential to be activated” 

• When there are variant domains with their own lifecycle, are there any other sources that bound the process?

• The chair responded that the same entity principle keeps the set together. It is acknowledged that there are circumstances where the registrant may no longer want the source domain and leaves it up to the registry and registrar on what to do.
• The team discussed this in Hamburg and decided not to make any explicit recommendations on what to do with the source domain in this case. It is not believed that registries would allow this domain to be re-allocated, but there are no explicit recommendations made to this effect. 

• A team member commented “The EPDP Team also had extensive discussion around whether the source domain name can be changed or deleted. One member proposed that it should be possible to delete or change a source domain name as long as its activated variant domain name(s) remain allocatable. The ultimate agreement among the team was to not to prescribe any policy recommendation pertaining to this matter. The EPDP Team understood that the specific details in the domain name lifecycle management are discretionary on part of registry operators and registrars, in accordance with their policies and practices. In addition, registry operators would not allow a situation where an activated variant domain name becomes “blocked” due to the change or deletion of the source domain name, as this would likely become a non-compliance issue with the IDN Table implementation.”
• Another team member suggested that there should always be a primary label in a set. If the primary domain is removed, another should be identified and flagged.

• The chair commented that as long as the source exists, even if it's not used, then the variants will still be operational.
• A different team member cautioned against explicitly mentioning instructions.
• A comment in chat stated: “Agree with thinking of this scenario as deactivation of source domain name instead of deletion if this intent is to allow the remaining variants of the set to still 'exist' in the same disposition value.”

• This comment received additional approval in chat.

• It was also cautioned that the team should not create new situations, rules, or terminology, 

• The chair commented that this is a challenge the team faces. There was an agreement not to dictate how the registries and registrars operate in these scenarios, but the discussions at this moment may be trying to challenge this agreement.

• ACTION ITEM: Staff will flag areas that are still contentious for review on the mailing list.

• Discussions will be tabled for this, and staff will create a glossary for review in KL to hopefully assuage the concerns created by this discussion.
• A team member commented: “As we are using these terms in policy recommendations, it will be useful to disambiguate all these terms: registration, allocation, activation.”

• Another team member commented “I don’t disagree, but I also don’t want to recreate those definitions if they already exist. Does ICANN have a working definition on these terms? Perhaps, let’s start there.” 

§ Staff will investigate and report back at the workshop

• Edits were described for PR6 and its rationale. These edits covered different areas throughout the lifecycle.

• A team member from the registries detailed discussions being held (and those that are scheduled) regarding the lifecycle as well as the Simultaneous / Same time discussion.

• ACTION ITEM: Staff will include time in the workshop to go over registry discussions on PR6. 
• Pending these conversations, the first paragraph on page 19 may need additional edits

• Additional comments in PR7 were discussed regarding court orders and staff consulted experts from the Transfer Policy PDP WG. There is a comment and footnote that the current transfer policy covers certain areas and that it does not have to be expanded upon further in the document.

• A team member asked staff to add “URS” after “UDRP” to cover possible circumstances. 

• Staff will review the transfer policy to see if URS is included. If not, it will not be included in the PR7 text. 

• A team member mentioned that URS remedies do not include transfer. Only suspension of the domain name
• URS will not be added to this text. 

• In C4a, terminology was updated for the global change (pending discussions at workshop).
• The D5 EPDP Team response was then described.

• AOB (3min)

• The chair asked the team to read through the text once again before the F2F so that everything is approved expeditiously in KL. 
• The leadership team will finalize the agenda for the F2F next week.
• The chair wished everyone safe travels and thanked everyone for their efforts.
• The chair also reminded the team of the upcoming GNSO Council meeting at 21 UTC today, 16 November.