[Gnso-epdp-idn-team] Notes from EPDP IDNs Sessions at ICANN78

[Daniel Gluck]

Moin!

Please find below the notes and action items from the three EPDP IDNs sessions in Hamburg.



Here are the wiki space pages for all three sessions:
Session 1: https://community.icann.org/x/KgGWDw
Session 2: https://community.icann.org/x/LAGWDw

Session 3: https://community.icann.org/x/LgGWDw



Best Regards,

Ariel, Steve, and Dan



SESSION 1 ACTION ITEMS

  *   Limited the text for the definition of Source Domain Name by linking to the recommendation, to avoid redundant or contradictory text.
  *   Revise definition to ensure adherence of the same entity principle and make clear that the disposition value is a part of the definition.

SESSION 1 NOTES

Roll Call and SOI Updates

  *   None

Welcome and Chair Updates

  *   Started consensus call on Phase 1 recommendations and today is the deadline. Heard back from registrars and ALAC. No response is assumed to mean support. Expect to hear from the GAC as well. Once midnight hits, it means we have hit an enormous milestone and will deliver the Final Report to the Council no later than 9 Nov.
  *   Goal for sessions at ICANN78 is to make progress on Phase 2 questions.

Continued Discussion of Source Domain: D4

  *   Slide 4: Refresher - Source Domain Name
  *   Slide 5: Open questions remain. Question 1: Should there be one source domain name per gTLD?
  *   Preliminary Agreement is that yes, there should be one source domain identified per gTLD.
  *   Slide 6: Example shows that the valid labels can differ between each gTLD, and a given variant.
  *   Persian, Arabic, Urdu use the same script, but languages might not use the same character set. Otherwise, no objections to the preliminary agreement.
  *   Slide 7: Question 2: Must the source domain name be register?
  *   Preliminary Agreement: The source domain name must be registered but may or may not be activated. No objection to the preliminary agreement.
  *   Slide 8: Michael B proposal - It should be possible to delete or change a source domain name as long as its active variant domain names remain allocatable.
  *   Slide 9: Question 3: Can a source domain name be changed or deleted?
  *   Preliminary Agreement: No need to prescribe policy recommendation in response to this question.
  *   Certain attributes of a domain name cannot be edited. The string in particular cannot be edited. It must be deleted and re-registered. If the source is deleted, the rest of the variants should also conclude their lifecycle. Essentially, there should be no remnants from the variant set.
  *   Slide 10: Source Domain Name and Variant Domain Set are suggested items to be included in the Glossary. Definitions are suggested and were read out to the team during the meeting.
  *   Suggestion to add: “should be at the second-level (or levels for which the registry provides registration for)”. Some concern that the recommendations have been limited to the second level.
  *   Suggestion that the recommendation should be limited to the second level since the contracts generally do not prescribe actions for the third level. Third level and beyond, if allowed, are generally up to the registrant to manage.
  *   Agreement with this comment and belief that this question is actually out of scope. IDN tables are actually not even required at the third level and beyond.
  *   Confirmation that the text related to the registrant and sponsoring registrar jointly identify the primary source domain is also captured as a recommendation.
     *   Suggestion to remove the last sentence since it’s also captured in the recommendation. Could also reference recommendation for clarity and consistency.
  *   Concern/question: Are we creating rules beyond the extent of IDNs? There are generally not variants for non-IDNs.
  *   Suggestion that the recommendations and definitions must be consistent. Agreement that this is indeed important.

Action Item: Limited the text for the definition of Source Domain Name by linking to the recommendation, to avoid redundant or contradictory text.



  *   For the Variant Domain Set definition, it is currently limited to the primary gTLD. Would it be extended to variant gTLDs? It would seem that this definition should be consistent with the preliminary agreement [add reference to agreement]
  *   Might need another layer to connect variant domain sets across gTLD variants. This coherence is needed to help ensure the same entity principle is applied across the gTLD variants.
  *   The definition is not clear whether or not the disposition values are a part of the set.
  *   Clarified that the top-level definition does in fact include the disposition value, so there might be a benefit to be consistent.
  *   Question whether the disposition terminology is the same for top-level and second level. Confirmation that the terminology is consistent.
  *   Suggestion that the definition should include domain names across all of the variant gTLDs, which would aid in the issue of ensuring same entity across the variant gTLDs.

Action Item: Revise definition to ensure adherence of the same entity principle and make clear that the disposition value is a part of the definition.

Identifying the Same Registrant: C3, C3a

  *   CPH TechOps was requested to provide a presentation on this topic.
  *   Slide 12: Preliminary Recommendation 2: The “same entity” principle applies to the activation of future variant domain names. This means that all allocatable variant domain names from a variant domain set must be activated or withheld for possible allocation only to the same registrant at the same sponsoring registrar.
  *   Slide 13: Context about charter questions C3 and C3a
  *   Slide 14: Domain Name Registration flow and parties involved.
  *   A person or entity wanting a certain domain name goes to a registrar, which communicates with the registry (via EPP). The EPP command is domain create, which includes the domain name and the required registrant information. This command is a billable transaction.
     *   The result is either a confirmation or an error output. If successful, the entry gets added to the database and registration data server.
     *   For variant activation (not necessarily registration, since it might not require an EPP command), it could be a create command (which would be billable) or an update command (which would not be billable).
  *   Need to consider resellers, who might not be able to easily determine or enforce same entity rules who are in some ways, like a registrant in terms of information known. Registrar sees the reseller contacts, not necessarily for the ultimate registrant.


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?


SESSION 3 ACTION ITEMS
Leadership will review the notes and transcript to best determine how to address Charter Question D5


SESSION 3 NOTES

  *   Roll Call and SOI Updates
  *   Welcome and Chair Updates
     *   The Chair welcomed everyone to the meeting and handed the mic over to GNSO Chair Sebastian Ducos for some remarks
        *   The GNSO Chair congratulated the EPDP team on achieving full consensus for the Phase 1 Final Report
        *   The EPDP Chair thanked the GNSO chair and congratulated the team as well
  *   Continued Discussion of Source Domain: D4
     *   Staff then introduced the topics for the day, including the continued discussion regarding the source domain.
        *   Staff asked if there was any comment or question from the team, but there was no objection for the rationale updates for Preliminary Rec 5
  *   Identifying the Same Registrant: C3, C3a
     *   Staff described the updates to developing responses to the charter questions C3 and C3a.
        *   This received approval in chat from multiple team members
  *   Variant Domain Transaction Fees: D5
     *   Staff described the preliminary recommendation to capture the agreement about mandatory annual fees for registration, renewal, or transfer for each REGISTERED variant domain name. Activated variant domain names would not be charged the annual fee.
        *   One team member commented that this might not be necessary. If a variant is not registered, then it doesn't get charged. They are not sure why it would have to be

           *   The chair replied that they would like to view the language in the registrar and registry agreements regarding this as it might not matter if it is in or not in a variant domain set. “A domain name is a domain name is a domain name”

              *   A team member commented in chat with the following excerpt from the registry agreement “The registry-level transaction fee will be equal to the number of annual increments of an initial or renewal domain name registration (at one or more levels, and including renewals associated with transfers from one ICANN-accredited registrar to another, each a “Transaction”), during the applicable calendar quarter multiplied by US$0.25”
                 *   Taken from Article 6, 6.1 Registry-Level Fees: https://itp.cdn.icann.org/en/files/registry-agreements/nrw/nrw-agmt-html-21nov13-en.htm
           *   Another team member commented “situation where some registries are to pay for each variant in the set and some not - is going to be a huge issue”
              *   They spoke about the possibility of angering regulators and tax agencies about this.
                 *   The chair mentioned they would like to get to an understanding where it doesn't matter if the registered domain is being used as part of a variant set or not. It should be treated equally
           *   A different team member questioned legal distinction between registration and activation
              *   The chair replied that registration is a specific process and that garners a fee being charged.
                 *   There is a need to clear up language regarding this
           *   The vice chair discussed the meaning of registration.
              *   “If the domain name is used, will it trigger fees”
           *   The vice chair continued,  what are the use cases of activating but not registering?
              *   One team member discussed the process of reserved domain names
                 *   If you change the property of a reserved variant, it should not incur a fee, they suggested.
              *   The GNSO Chair discussed that Reserved Names are set aside for future registrations. If the name applied for is on this list of set asides, then the application fails.

·         They are not sure how this applies to this question.

           *   A team member posted: “if the result of activation is indistinguishable from the results of the activation - there is an issue in courts around the globe. it sounds pretty much like an allocation without the registration. I think registered domains without NS records are still used , at least as a proof in UDRP or courts. fees are not applicable to reserved names. reserved might be different from allocation or can mean the same depends on the implementation. fees are for registered domains”
              *   They continued by talking about the process including escrow and accounting. For the reasons of potentially

                 *   Another team member described the two labels that can be applied for registrars regarding this process in EPP: Escrow and Not a Domain Name (NADN)
           *   The chair mentioned that this depends on the registry policy
              *   A team member from the RySG mentioned that if the registry policy says that a variant domain name is the same as a regular domain name, then it goes through the regular reporting and billing process.
              *   If variant domain names are qualified in a different way, then they won't trigger the billing process.
           *   The same entity principal enforcement is also going to be key, per a different team member.
        *   The chair mentioned that there is a fee associated with each domain name. Leadership will research appropriate language that will future proof for variant domains at the second level. It should not be convoluted and can probably be thought of as being straight forward.
           *   ACTION ITEM: Leadership will review the notes and transcript to best determine how to address Charter Question D5.
        *   A team member asked whether or not ICANN receives a fee for every registered domain name. If yes, they believe there should be a fee. Whether or not a registry charges for variants, they should have to pay for them. If they want to make it free, then it is a marketing expense.
        *   A member of staff asked if there are different ways for domains to come into the DNS and serve content, but some can be billable and some cannot.
           *   One way to instantiate a domain is to put an EPP create command in, which creates a billable transaction
           *   Another method is to activate a domain, it serves content, but it is not billable.
              *   There is not alignment on this, but this seems to be the general understanding
        *   The chair is not concerned with updating processes and lower-level information; they are concerned at the high level.
        *   The GNSO chair delineated transaction vs domain names. ICANN will match the amount of domain names to what the registrars report.
  *   AOB
     *   The chair thanked Dennis Tan for his fantastic work and efforts for this group subject matter.
     *   Staff provided an update on the final reporting process, pursuant to the final deadline of 7 November for delivery to the GNSO council.
     *   The chair announced they would like to finish all charter questions by the time they leave the Kuala Lumpur Face-to-Face meeting.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20231025/ebbd1702/attachment-0001.html>