ICANN 55 Quick Guide: Difference between revisions
Dustin Loup (talk | contribs) No edit summary |
Dustin Loup (talk | contribs) No edit summary |
||
| Line 87: | Line 87: | ||
On 23 February 2016, after the necessary changes had been made the CCWG released the supplemental final proposal in time for the Chartering Organizations to deliberate prior to ICANN 55. If it is approved by all of the organizations, the proposal will be ready to submit to the ICANN Board, which will then be able to send the a complete proposal to the NTIA. | On 23 February 2016, after the necessary changes had been made the CCWG released the supplemental final proposal in time for the Chartering Organizations to deliberate prior to ICANN 55. If it is approved by all of the organizations, the proposal will be ready to submit to the ICANN Board, which will then be able to send the a complete proposal to the NTIA. | ||
</div> | </div></div> | ||
<div class=" mw-collapsible mw-collapsed"> | <div class=" mw-collapsible mw-collapsed"> | ||
<h2 class="sectionheader2"><span style="margin:25px 0 0 15px">Next-Gen RDS</span></h2> | <h2 class="sectionheader2"><span style="margin:25px 0 0 15px">Next-Gen RDS</span></h2> | ||
Revision as of 05:14, 1 March 2016
Welcome to Marrakech
ICANN 55 in Marrakech, Morocco takes place from 5-10 March 2016. A lot has happened since ICANN 54 in Dublin. With important issues such as the IANA Transition and ICANN Accountability nearing the finish line, ICANN 55 looks to be a historic meeting. Additionally, it marks the final meeting for Fadi Chehadé as President and CEO of ICANN.
If you want to catch up on recent developments or learn more about the important issues currently being addressed, this primer will serve as your go to guide for ICANN 55. If you have further questions or want further background, our site has approximately 6,000 articles on the people, organizations, terms and topics within the ICANN Community. You will find this Primer is well-linked to our relevant articles and anything articles that are not linked can be accessed by searching our site.
ICANN 55 - Meeting Details
Edit-a-Thon
Key Topics
IANA Transition
- Support and enhance the multistakeholder model
- Maintain the security, stability, and resiliency of the Internet DNS
- Meet the needs and expectations of the global customers and partners of the IANA services
- Maintain the openness of the Internet
In response, ICANN formed the IANA Stewardship Transition Coordination Group (ICG), made up of 30 members from 13 constituencies, to develop the structure and timeline for finalising the proposal, which requires proposals from the communities directly affected by the IANA functions. Each of these communities developed their own working groups to develop their proposal:
- The Numbering Resources Community, comprised of the Numbers Resources Organization (NRO), the Address Supporting Organization (ASO) and the five Regional Internet Registries (RIR) formed the Consolidated RIR IANA Stewardship Proposal Team (CRISP Team) to develop their proposal.
- The Protocol Parameters community, comprised of the Internet Engineering Task Force (IETF) and the Internet Architecture Board (IAB), formed the IANAPLAN Working Goup.
- The Domain Names community, developed two working groups the CWG-Stewardship and the CCWG-Accountability.
On 29 October 2015, the ICG announced that it had finalised all of the proposals from the community, except for the one from the CCWG-Accountability, which is currently in its final stages. If everything proceeds as planned the community will submit the final proposal to take over stewardship of the IANA functions on 10 March 2016, the last day of ICANN 55.
Enhancing ICANN Accountability
In December 2014, the CCWG-Accountability began working on the proposal to enhance ICANN Accountability. The process was divided into two Work Streams. Work Stream 1 is focused on accountability mechanisms that need to be in place prior to the transition. Work Stream 2 is focused on accountability measures that can be implemented post-transition. The CCWG identified four “building blocks” for the mechanisms that need to be in place pre-transition: Principles that form the Mission and Core Values of ICANN; Empowered Community; ICANN Board of Directors; Independent appeal mechanism;
After several iterations, the CCWG released its third draft proposal on 30 November 2015, which was the culmination of two prior draft proposals and almost a year of hard work. This third proposal set forth twelve recommendation for the accountability measures needed to enhance ICANN accountability.
The key elements of the third proposal include: Revised Mission statement for ICANN Bylaws, that clarifies what ICANN does but does change the scope of its mission of coordinating the Internet’s unique identifiers for the Internet. Enhanced Independent Review Process to ensure that ICANN stays within its mission. New community powers to be used to hold the Board of Directors Accountable.
Enforceability of the accountability measures will be supported by the creation of an “Empowered Community,” which will be granted the legal status of a Designator within ICANN and is designed to act on behalf of the ICANN stakeholder groups when they are required to exercise their community powers. The CCWG has stressed that the new community powers are only to be utilized after all other means are exhausted. The community is to follow the model of engagement, escalation, enforcement.
After this proposal went through the public comment period ending on 21 December 2015 and the staff report was released on 7 January 2016 , the CCWG determined that there were only a few outstanding issues that needed to be addressed to reach consensus on a final proposal and planned a rigorous schedule of conference calls over the next few weeks to reach a consensus on a final supplemental report on Work Stream 1 recommendations.
On 23 February 2016, after the necessary changes had been made the CCWG released the supplemental final proposal in time for the Chartering Organizations to deliberate prior to ICANN 55. If it is approved by all of the organizations, the proposal will be ready to submit to the ICANN Board, which will then be able to send the a complete proposal to the NTIA.
Next-Gen RDS
WHOIS was created in the 1980s as a service to identify network operators on the Internet. Since this time, the Internet has changed far beyond expectations, evolving from a research network into a global commercial network that is integrated into everyday life. The usage of WHOIS has changed along with the evolution of the Internet, but the protocol has changed very little.
Consequently, the WHOIS protocol as it exists today has several deficiencies that are becoming increasingly apparent to the community. Some of the pressing issues include: data accuracy and reliability accessibility for users whose local language cannot be represented in ASCII data protection and privacy concerns
Despite a series of task forces, working groups, workshops, surveys and studies over the last 15 years, the various issues with WHOIS policy and protocol still need to be addressed. The entire community of stakeholders are affected by WHOIS, bringing a wide variety of diverse concerns and interests to the table for discussion.
In 2010, ICANN formed the WHOIS Review Team, guided by the Affirmation of Commitments to review the are effectiveness of ICANN’s WHOIS policy and implementation, as well as if it meet the needs of the law enforcement community and promotes consumer trust. In response to the Review Team’s Final Report (2012), the ICANN Board passed a resolution to launch the Expert Working Group on gTLD Registration Directory Services (EWG) to “redefine the purpose of collecting, maintaining and providing access to gTLD registration data, and consider safeguards for protecting data” and to propose a new model for Registry Directory Services (RDS) that addresses the issues outlined above. Additionally, the Board’s resolution called for a GNSO Policy Development Process, to be informed by and address the issues in the EWG’s Final Report.
The EWG released its final report in 2014, initiating the process of structuring the Next-Generation gTLD Registration Directory Service to replace WHOIS PDP WG (Next-Gen RDS PDP WG). The PDP will be a three step process: Establish gTLD registration data requirements to determine if and why a next-gen RDS is needed. Design policies that detail functions that must be in place to support those requirements. Provide guidance for how the next-gen RDS should implement those policies, including coexisting with and replacing WHOIS.
The process is currently in Phase One, in which the Next-Gen PDP WG aims to reach consensus recommendations, through analysis of several key questions, relating to the uses/purposes of RDS, who should have access to the data, data accuracy, privacy, steps for replacing WHOIS and other important issues.
Running parallel to this process, is the Public Comment period on the Registration Data Access Protocol (RDAP) Operational Profile for gTLD Registries and Registrars, which is a likely candidate to eventually replace WHOIS. The RDAP was developed by the IETF’s Web Extensible Internet Registration Data Services (WEIRDS) WG. Some major improvements that come with the RDAP include a standardized data model, internationalization for non-ASCII languages, and differentiated access.
As these processes develop, the outdated WHOIS Policy and Protocol will receive an overdue update, making improvements on the issues of accuracy, privacy and access. The Next-Gen PDP WG will hold their first face-to-face meeting at ICANN 55 to work toward their phase one goals.
Next-Gen RDS
Universal Acceptance is the state in which all valid domains names are useable in all Internet enabled applications, devices, and systems regardless of length, script, or newness to the DNS.
The issue of Universal Acceptance has been present since the 2000 gTLD expansion round, but has been exacerbated by the introduction of IDN’s and ICANN’s new gTLD Program, which has introduced over 900 new TLDs to the DNS root zone.
Prior to the early 2000s, developers of user interfaces and security rules made certain assumptions about TLDs: Valid TLDs include, three letter TLDs, such as .com, .org, .gov, etc and ccTLDs, based on the ISO 3122 two letter codes TLDs and email addresses contained only ASCII The Root Zone is relatively static, with few changes made
In the early 2000s, the gTLD expansion made assumption of TLD length obsolete. TLD lengths became even more varied with the implementation of ICANN’s new gTLD Program. Also in 2010, the first IDN was introduced, which broke the assumption that ASCII is the only valid character set, introducing UTF-8. The final assumption was then broken by the new gTLD Program, which made the root zone much more dynamic, with new TLDs and IDNs being added every week.
Universal Acceptance is currently being addressed by the community through several initiatives, including the Universal Acceptance Steering Group (UASG), chartered in March 2015. The UASG’s primary objective is to help developers and website owners understand how to update their systems to treat all TLDs consistently, which will enable more customer choice, faith in the DNS and allow users of IDNs to fully utilize the Internet.
The UASG and ICANN launched a Universal Acceptance study for new gTLDs and reported the results in September 2015. The study and report: An Analysis of New gTLD Universal Acceptance, found that there were no problems with Universal Acceptance on the infrastructure level and that non-IDNs performed strongly across the board. However, IDNs still require some changes to software and systems to be reach full usability. Particularly complex and interesting issues arise in regard to scripts that run from right to left.
Usability of TLDs and IDNs requires five criteria outlined above in the UASG’s definition of Universal Acceptance: Acceptance - Web applications and services that take domain names and email addresses as inputs should accept all valid extensions. Validation - obsolete techniques and criteria used to validate domain names and email addresses should be updated Storing - Applications and services require storage of domain names and email addresses, should be stored in RFC-defined or other compatible formats. Processing - Domain names or email addresses should be able to be processed in programs or features without issues. Displaying - Domain names and email strings should be properly displayed to users. This includes displaying the address in the proper script, without displaying the punycode text.
The work on Universal Acceptance will not be complete until “all valid domain names and email addresses are accepted, validated, stored, processed, and displayed correctly and consistently by all Internet-enabled applications, devices and systems.” At ICANN 55, the UASG will be holding an all day workshop for participants to develop solutions to the issues.