Page History

A. Consistent definition and technical utilization of RZ-LGR

• a1: RZ-LGR as  sole authoritative source
• a2: Any standing of self-identified variants
• a3: Any challenge process to RZ-LGR variant dispositions
• a4: Where script of application not supported by RZ-LGR
• a5: Any ceiling value for variant allocation 
• a6: Impact of possible non-full backward compatibility of future version of RZ-LGR on existing delegations
• a7: Allowing single character IDNs
• a8: Catch-all
• a9: TLD label statuses (taxonomy)
• a10: TLD label statuses (changes)

• a1: PR 1.1: RZ-LGR as sole source to calculate variant labels, disposition values
• a2: No recommendation needed
• a3:  

  • PR 3.22: 

    • String must conform to mandatory string requirements and RZ-LGR to be submitted in application system
    • If initial algorithmic check says string is “invalid” or “blocked” application can be accepted but applicant must be warned of potential disqualification
    • If DSP confirms “invalid” or “blocked”, application is disqualified but applicant can invoke limited challenge mechanism
    • Grounds of challenge limited to “incorrect assessment of technical implementation of RZ-LGR”
  • IG 3.23: Application system should issue disqualification warning if initial algorithmic check says string is “invalid” or “blocked”
  • PR 3.24: Disqualification remains unless and until string deemed valid and allocatable in future RZ-LGR
• a4: No recommendation needed 
• a5:

• Ceiling value for variants
  • PR 8.1: No ceiling value for delegated TL variant labels from a variant label set
  • PR 8.2: Framework for developing guidelines for management of gTLD and variant labels at TL by registries and registrars must be created during implementation
  • IG 8.3: The framework (per PR 8.2) should outline the scope and the steps 
    involved in developing future guidelines, which at a minimum should involve relevant stakeholders, such as registries, registrars, and where feasible, registrants who have experience with IDNs and variant labels
    
• a6: Grandfathering for RZ-LGR
  • PR 8.6: Any delegated gTLDs and their delegated and allocated variant labels (if any) not validated by a proposed RZ-LGR update must be grandfathered

  • PR 8.7: For all future versions of the RZ-LGR, GPs and the IP must make best efforts to retain full backward compatibility with delegated gTLDs and their delegated and allocated variant labels (if any). The LGR Procedure must be updated to specify the exceptional circumstances, to the extent known to the GPs and IP, that could result in a proposed update to the RZ-LGR not being able to retain full backward compatibility.

  • PR 8.8: In the unexpected event where a proposed update to the RZ-LGR is unable to retain full backward compatibility for validating any delegated gTLDs as well as their delegated and allocated variant labels (if any), the relevant GP must call out the exception during a Public Comment period and explain the reasons for such exception. The Public Comment period should also include the elements in IG 8.9

  • IG 8.9: The GP analysis should identify security and stability risks (if any), as well as possible actions to mitigate the risks associated with allowing a delegated gTLD and its delegated and allocated variant labels (if any) to be grandfathered. There should also be an assessment, conducted by ICANN org, of the potential impact of grandfathering on registries, registrars, registrants, and end-users, as well as proposed measures to reduce the negative impact. As part of the assessment, ICANN org should facilitate a timely dialogue between the registry operator of the grandfathered gTLD, relevant function(s) in ICANN org, the GP, other experts and affected parties.

    Notwithstanding the recommendation to grandfather affected gTLDs, in the event security and stability risks are identified, ICANN org and the affected registry operator should discuss possible measures to minimize the risks that would result in minimal disruption to registries, registrars, registrants, and end-users

• a7: PR 3.17:Only languages where character is an ideograph are eligible to have single-character gTLD i.e. only Han script for now, but not until relevant guidelines from CJK GPs are developed, implemented
• a8: No recommendation, more related to SL DN registrations
• a9: Label states
  • PR 9.1: A given variant label must have one of the following label states at any one time: delegated, allocated, withheld-same-entity, blocked, or rejected. If the same terminology is used for certain label states and new gTLD application states, their respective definitions must be consistent
    
  • IG 9.2: The label state for each variant label of an already delegated primary gTLD should be recorded and tracked by ICANN org so long as the primary gTLD remains delegated. Such records, including historical ones, should be maintained in a practical manner and made publicly accessible.
• a10: PR 9.3: Transition states of a variant label & IG 9.4: scenarios for variant label state transition

B. IDN Variant TLD Management: "Same entity" at the top-level

• b1: Same entity top level
• b2: Same entity back end
• b3: Any additional requirements beyond b1 and b2
• b4: Process to obtain variant labels
• b4a: Role of "withheld for same entity"
• b5: Extension of restrictions on community, brand to variant labels

• b1: PR 2.1: Allocatable variant label for existing IDN gTLD from 2012 round only allocatable or withheld for that registry operator
• b2:

  • PR 7.7: The registry service provider for each one of the Critical Functions as defined in the Base RA for an existing IDN gTLD from the 2012 round must be the same as for its delegated variant labels.The Critical Functions are: DNS Service, DNSSEC proper resolution, EPP, RDDS, and Data Escrow.

  • PR 7.8: If the registry operator of an IDN gTLD changes its back-end registry service provider, that IDN gTLD and any delegated variant label(s) associated with that IDN gTLD must simultaneously transition to the new back-end registry service provider.

• b3: No recommendation needed
• b4:
  • PR 3.1: Allocatable variant label cannot precede primary
  • PR 3.2: Future registry operator can only apply for allocatable variant label during application round
  • PR 8.4: Same delegation timeframe for primary and allocatable variant labels that pass evaluation, same terms and conditions including ability for extension of time for delegation
  • PR 8.5: Sequence of delegation of labels that pass evaluation is up to registry operator
• b4a: No recommendation
• b5:
  • PR 3.16: Applied for allocatable variant label must be treated the same as its primary in terms of requirements - Community-based, Geoname, .Brand
  • PR 7.15: Applied-for primary and allocatable variant labels must be bound by the same restrictions which will become contractual requirements in RA. Same with allocatable variant labels for existing IDN gTLDs. (Restrictions meaning for Community-based, Geonames, .Brand TLDs, TLDs subject to Cat 1 Safeguards)

C. IDN Variant TLD Management: "Same entity" at the second-level

• c1: Same entity second level
• c2: Reconcile SubPro rec with existing RA
• c3: Mechanism to identify registrant - ROID
• c3a: If use ROID, anything else?
• c4: Harmonization of IDN tables; consider existing SLD
• c4a: Disposition of variant labels across TLD can differ
• c5: Methods to harmonize IDN tables
• c6: Use of RFC7940

• c1: Phase 2
• c2: Phase 2
• c3: Phase 2
• c3a: Phase 2
• c4: Phase 2
• c4a: Phase 2
• c5: Phase 2
• c6: Phase 2

D. Adjustments in registry agreement, registry service, registry transition process, and other processes/procedures related to the domain name lifecycle

• d1: Legal framework
• d1a: Registry Agreement
• d1b: 'Application' for future variant TLDs
• d2: Lifecycle management of variant TLDs
• d3: Same entity data escrow impact
• d4: Same entity lifecycle second level
• d5: Registration fees second level
• d6: Transfer second level, voluntary and involuntary
• d6a: UDRP impact on same entity principle
• d7: Suspension of 1 domain impact to variant set
• d7a: URS impact on same entity
• d8: Catch-all

• d1: No recommendation needed
• d1a: Contractual Reuirements
  • PR 7.1: Any future IDN gTLD along with its variant labels (if any) must be subject to one Registry Agreement
  • IG 7.2: A new specification or an amendment to the base RA for any future IDN gTLD along with its variant label(s) may need to be developed to incorporate variant management provisions.

  • PR 7.3: Any existing IDN gTLD registry operator from the 2012 round that applies for its variant labels in the future must be required to enter into a separate, new RRA for the newly approved variant label(s), while maintaining the existing RA for its existing IDN gTLD

  • IG 7.4: It is expected that the separate, new RA for the newly approved variant labels will be linked in some way to the RA for the existing IDN gTLD from the 2012 round
• d1b:
  • PR 3.3: Existing IDN gTLDs registry operators can only apply allocatable variant labels during application round 
  • PR 3.4: Future IDN gTLD primary and allocatable variants labels in one application 
  • PR 3.5: Both future IDN gTLD and existing registry operators who want allocatable variant labels must explain why they seek those variant label
  • IG 3.6: Criteria for evaluating explanations (per PR 3.5) should be pre-identified and applied consistently by qualified
  • PR 3.7: Both future IDN gTLD and existing registry operators who want allocatable variant labels must demonstrate ability to manage primary and variant labels from technical and operational perspective
  • IG 3.8: Evaluation (per PR  3.7) should be closely tied to overall technical capability evaluation with criteria including Critical Functions with respect to SL registrations
  • IG 3.9: ICANN org may do research to help identify additional standards or test for technical and operational capability evaluation (per PR 3.7)
  • PR 3.10: Fee structure for all future applications must be consistent with principle  of cost recovery 
  • PR 3.11: Future applicant for primary and up to 4 allocatable variant labels must incur base application fee
  • PR 3.12: Any applicant applying for more than 4 allocatable variant labels may incur additional fees determined by ICANN org
  • PR 3.13: Future registry operator applying only for allocatable variant labels must incur discounted base application fee

  • PR 3.14: 

    • Existing registry operator applying for up to 4 allocatable variant labels of existing IDN gTLD in the immediate next round will have base application fee waived.

    • If beyond immediate next round then must incur discounted base application fee.

    • If apply for more than 4 existing IDN gTLD in the immediate next round then may incur additional fees. 

    • If beyond immediate next round then must incur discounted base application fee and may incur additional fees.

  • PR 3.15: One-time exception in the immediate next application round, existing IDN gTLDs applications for allocatable variant labels to receive priority in processing order

  • PR 7.5: The registry fixed fee for an IDN gTLD registry operator that operates the delegated gTLD label(s) from a variant label set must be the same as a gTLD registry operator of a single gTLD.

  • PR 7.6: The calculation of the registry-level transaction fee must be based on the cumulative number of domain name registrations of the combined delegated gTLD label(s) from a variant label set
• d2: 
  • PR 7.9: In the event a Registry Transition or Change of Control process is initiated for an IDN gTLD, the process must encompass the IDN gTLD and all its allocated and delegated variant label(s), if any, at the same time.
    
  • PR 7.10:After the Registry Transition Process or Change of Control process is completed for an IDN gTLD and its allocated and delegated variant label(s), only the successor registry operator can apply for the other non-delegated, allocatable variant label(s) of that IDN gTLD
  • PR 7.11: Emergency transition of an IDN gTLD to an EBERO provider 
    must include the allocated  and delegated variant label(s) of that IDN gTLD, if any. All these labels must be transitioned to the same EBERO provider at the same time
    
  • PR 7.12: In the event an IDN gTLD is reassigned as a result of a TMPDDRP determination, that reassignment must include all allocated and delegated variant label(s) of the IDN gTLD, if any, at the same time
• d3: 
  • PR 7.13: The same data escrow provider must be contracted for the IDN gTLD and its allocated and delegated variant label(s).
  • IG 7.14: The escrow data associated with each gTLD variant label should be stored in separate files
• d4: Phase 2
• d5: Phase 2
• d6: Phase 2
• d7: Phase 2
• d7a: Phase 2
• d8: Catch-all
  • PR 8.10: A primary IDN gTLD that is removed from the root zone, either voluntarily or involuntarily, must also require the removal of its delegated variant label(s) from the RZ.
  • PR 8.11: A delegated variant label that is voluntarily removed from  the root zone will not require the removal of the associated primary IDN gTLD or its other delegated variant label(s).
    
  • PR 8.12: In the event that a label is removed from the root zone as a consequence of its registry operator’s breach of the RA, its associated variant label set must also be removed from the RZ
    

E. Adjustments to objection process, string similarity review, string contention resolution, reserved strings, and other policies and procedures:

• e1: Role of "withheld for the same entity"
• e2: Criteria for objection
• e3: String similarity (scope)
• e3a: String similarity (consequences)
• e4: String contention resolution
• e5: Reserved strings & strings ineligible for delegation
• e6: 2-character Latin IDN TLDs
• e7: Catch-all (same entity - top level)

• e1: Same as B4a, no recommendation
• e2:
  • PR 5.1: All applied-for allocatable gTLD variant labels must be subject to the objection processes
  • PR 5.2: A String Confusion Objection may be filed based on confusing similarity between combinations of applied-for primary gTLD strings and their variant labels established by Hybrid Model and SSPR exception - 8 scenarios included
  • Only a blocked variant label of an applied primary claimed as confusingly similar to the blocked variant label of an existing gTLD/ccTLD or another applied-for primary string cannot be the basis of SC Objection.

  • PR 5.3: Outcomes of String Confusion Objection consistent with 2012 AGB - 3 scenarios included

  • PR 5.4: Permissible circumstances for Limited Public Interest Objection, Legal Rights Objection, and Community Objection - an objection may be filed against only the applied-for primary gTLD strings and/or the applied-for allocatable variant labels - 3 scenarios specified

  • PR 5.5: Possible outcomes for Limited Public Interest Objection, Legal Rights Objection, and Community Objection:

    • If an objection against an applied-for primary gTLD string prevails, then that application (in its entirety) is ineligible to proceed 
    • If an objection against only one or more applied-for allocatable variant label(s) prevails, then that application for the applied-for primary gTLD string and other unaffected applied-for allocatable variant label(s) may proceed without the applied-for allocatable variant label(s) which are rendered ineligible by the objection
    • If the objection does not prevail, then that application (in its entirety) may proceed
• e3: String Similarity
  • PR 4.1: Modify String Similarity Review to Hybrid Model
  • PR 4.2 String Similarity Review Panel may decide whether and what blocked variant labels to omit in review but must be based on guidelines and/or criteria on basis of manifestly low level of confusability
  • PR 4.3: Guidelines and/or criteria (per PR 4.2) must be developed during implementation
• e3a: PR 4.4: Integrity of set requires that all labels in a variant label set must share same outcome out of String Similarity Review:
  • If an applied-for primary or any of its variant labels is confusingly similar to an existing gTLD or ccTLD or any of its variant labels, then the entire variant label set will be ineligible to proceed.
  • If an applied-for primary or any of its variant labels is confusingly similar to another applied-for primary or any of its variant labels, then the entire variant label set will be placed in a contention set
• e4: String Contention
  • PR 6.1: An applied-for primary gTLD string that is also a variant label  of another applied-for primary gTLD string, as calculated by the RZ-LGR, must be placed in a contention set.
  • PR 6.2: The entire variant label set of an applied-for primary gTLD string (no matter whether it is an ASCII string or an IDN string) must be processed in the contention set.

• e5 - Reserved Names:
  • PR 3.18: Reserved Names list to not be expanded to include variant labels
  • PR 3.19: Variant labels of Reserved Names not allowed
• e5 - Strings ineligible for delegation:
  • PR 3.20: List of Strings Ineligible for Delegation to not be expanded to include variant labels
  • PR 3.21: Only the protected orgs on list of Strings Ineligible for Delegation can apply variant labels of their protected strings; but only if they also apply for or have the primary
• e6:

• No recommendation
• e7:

• No recommendation

• f1: Same entity impact to TMCH top level
• f2: Same entity impact to RPMs, URS, UDRP, etc top level

• f1:

• Phase 2
• f2:

• Phase 2

• g1: Process to update IDN Guidelines
• g1a: Differentiation for ccTLDs and gTLDs?

• g1:

• Phase 2
• g2:

• Phase 2