Changes

Jump to navigation Jump to search
Line 12: Line 12:  
==History==
 
==History==
 
In October 2020, an IDN scoping team released its Final Report, which recommended an EPDP, which the GNSO Council initiated in November 2020. The charter drafting team built on the existing body of work on IDNs, such as recommendations from the [[Sub Pro|gTLD Subsequent Procedures PDP]], IDN variant TLD implementation, and the Root Zone Label Generation Rules ([[RZ-LGR]]). On May 10, 2021, the drafting team submitted its deliverables, such as the definition of all gTLDs and the management of variant labels and how IDN Implementation Guidelines should be updated. Ten days later, the GNSO Council approved the initiation request for the EPDP-IDNs and adopted its charter. The EPDP-IDNs working group held its first meeting on 11 August 2021.
 
In October 2020, an IDN scoping team released its Final Report, which recommended an EPDP, which the GNSO Council initiated in November 2020. The charter drafting team built on the existing body of work on IDNs, such as recommendations from the [[Sub Pro|gTLD Subsequent Procedures PDP]], IDN variant TLD implementation, and the Root Zone Label Generation Rules ([[RZ-LGR]]). On May 10, 2021, the drafting team submitted its deliverables, such as the definition of all gTLDs and the management of variant labels and how IDN Implementation Guidelines should be updated. Ten days later, the GNSO Council approved the initiation request for the EPDP-IDNs and adopted its charter. The EPDP-IDNs working group held its first meeting on 11 August 2021.
In August 2022, the working group completed its first substantive deliberations on questions related to
+
In August 2022, the working group completed its first substantive deliberations on questions related to four topics.
# the definition of all gTLDs using the RZ-LGR,
+
===Drafting First Group Recommendations===
 +
As of December 2022, the EPDP Team had developed draft the following draft recommendations.
 +
# The definition of all gTLDs using the RZ-LGR:<ref>[https://community.icann.org/pages/viewpage.action?pageId=176622687 Working Documents, EPDP on IDNs], Accessed January 5, 2023</ref>
 +
#:The EPDP Team recommends that
 +
#*the RZ-LGR be the sole source to calculate the variant labels and disposition values for existing delegated gTLD labels.
 +
#* SubPro’s limited challenge mechanism for DNS Stability Review applies in cases where the applicant believes that the label is valid as per the RZ-LGR and that the DNS Stability Panel has incorrectly assessed the label as "invalid", thus resulting in the application having been incorrectly disqualified.
 +
#*No ceiling value is necessary as existing measures in the RZ-LGR to reduce the number of allocatable top-level variant labels, as well as economic, operational, and other factors that may impact the decision to seek to activate variant labels will keep the number of activated top-level variant labels conservative.
 +
#*Best practice guidelines should be developed for the management of a gTLD and its variant labels by registries and registrars with a view to ensuring a consistent user experience.
 +
#*Any existing gTLDs and their delegated and allocated variant labels (if any) not validated by a proposed RZ-LGR update must be grandfathered. In other words, the proposed update will apply to future new gTLDs and their variant labels and will not be retrospective; there will be no change to the contractual and delegation status of existing gTLDs and their delegated and allocated variant labels (if any), which predate the proposed RZ-LGR update and are subject to the version of RZ-LGR when those labels were delegated or allocated.
 +
#*For all future versions of the RZ-LGR, Generation Panels (GPs) and the Integration Panel (IP) must make best efforts to retain full backward compatibility with existing 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.
 +
#*In the unexpected event where a proposed update of the RZ-LGR is unable to retain full backward compatibility for validating any existing 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 “same entity” principle at the top level,  
 
# the “same entity” principle at the top level,  
 
# variants’ impact on the [[New gTLD Program]], and  
 
# variants’ impact on the [[New gTLD Program]], and  
Bureaucrats, Check users, lookupuser, Administrators, translator
14,952

edits

Navigation menu