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:  
  • a4: No recommendation needed 
  • a5: 
  • a6: 
  • a7 part 1: 
  • a7 part 2: 
  • a8: Parked since is catch-all question
  • a9: 
  • a10: 

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: 
• b3: No recommendation needed
• b4: PR 3.1: Allocatable variant label cannot precede primary
• b4a: PR 3.2: Future registry operator can only apply for allocatable variant label during application round
• b5: 

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: Parked, to defer (Group 4 CQ)
• c2: Parked, to defer (Group 4 CQ)
• c3: Deferred (Group 4 CQ)
• c3a: Deferred (Group 4 CQ)
• c4: Deferred (Group 4 CQ)
• c4a: Deferred (Group 4 CQ)
• c5: Deferred (Group 4 CQ)
• c6: Deferred (Group 4 CQ)

• • 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: 
• a6: 
• 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: 
• a9: 
• a10: 

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: 
• b3: No recommendation needed
• b4: PR 3.1: Allocatable variant label cannot precede primary
• b4: PR 3.2: Future registry operator can only apply for allocatable variant label during application round
• b5: 

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: Parked, to defer (Group 4 CQ)
• c2: Parked, to defer (Group 4 CQ)
• c3: Deferred (Group 4 CQ)
• c3a: Deferred (Group 4 CQ)
• c4: Deferred (Group 4 CQ)
• c4a: Deferred (Group 4 CQ)
• c5: Deferred (Group 4 CQ)
• c6: Deferred (Group 4 CQ)

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

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: Rec 2.4 Stable (Group 2 CQ)
• d1b: PR 3.4: Future IDN gTLD primary and allocatable variants labels in one application 
• d1b part 2: draft text circulated for 1st reading 
• d2: Rec 3.4, Rec 3.5, Rec 3.6 & Rec 3.7 pending 2nd reading (Group 3 CQ)
• : 
• 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
• d2: 
• d3: d3: Rec 3.8 & IG 3.9 pending 2nd reading (Group 3 CQ)
• d4: Deferred (Group 5 CQ)
• d5: Deferred (Group 5 CQ)
• d6: Deferred (Group 5 CQ)
• d7: Deferred (Group 5 CQ)
• d7a: Deferred (Group 5 CQ)
• d8: Parked since is catch-all question (Group 5 CQ)

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 part 1 on string similarity: Deliberations ongoing on String Similarity Small Group recommendation (Group 3 CQ)
• e2 part 1: Rec 3.1 Stable (Group 3 CQ)
• e1 part 2 on objections: Deliberations ongoing on String Similarity Small Group recommendations on String Similarity Small Group recommendations (Group 3 CQ)
• e2 part 2: In deliberation (Group 3 CQ)
• e3: Deliberations ongoing on String Similarity Small Group recommendation (Group 3 CQ)
• e3a: Parked, pending deliberations on SS Small Group recommendation (Group 3 CQ)e2
• part 2: In deliberation e4: Parked, pending deliberations on SS Small Group recommendation (Group 3 CQ)
• e3: Deliberations ongoing on String Similarity Small Group recommendation (Group 3 CQ)
• e3a: Parked, pending deliberations on SS Small Group recommendation (Group 3 CQ)
• e4: Parked, pending deliberations on SS Small Group recommendation (Group 3 CQ)
• e5 part 1: Rec 3.2 Stable (Group 3 CQ)
• 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
  e5 part 2: Draft text circulated for 1st reading 
• e6: Draft text circulated for 1st reading 
• e7: In deliberation (Group 3 CQ)

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

• f1: Deferred (Group 6 CQ)
• f2: Deferred (Group 6 CQ)

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

• g1: Deferred (Group 7 CQ)
• g2: Deferred (Group 7 CQ)