ICANN Correspondence



  • Minimal User Impact Expected From Root Zone Key Signing Key (KSK) Rollover
    on July 18, 2018 at 7:00 am

    The ICANN organization believes that an update of the Domain Name System Security Extensions (DNSSEC) trust anchor for the global Domain Name System (DNS) on 11 October 2018 will affect only a very small number of DNS users. The decision to roll the root zone Key Signing Key (KSK) is being made after a significant outreach effort and careful consideration of all available data. Since the DNS root zone was originally signed in 2010, the DNSSEC Practice and Policy Statement1 has set the expectation that the root zone KSK will change. Fortunately, most validating resolvers that observe a new root zone KSK should be able to configure it as a new trust anchor automatically using "Automated Updates of DNS Security (DNSSEC) Trust Anchors," defined in RFC50112. A resolver operator can also update their trust anchor configuration manually if they have become aware that the root KSK is changing based on ICANN's various outreach efforts. There is no standardized or deterministic way to actively measure that a validating resolver has the correct set of trust anchors configured. The best method currently available is "Signaling Trust Anchor Knowledge in DNS Security Extensions" (documented in RFC 81453) that was published in April 2017. In that protocol, validators emit a DNS query that contains the DNSKEY key IDs of configured trust anchors in the query name. These queries can be passively observed in traffic at the root servers. In September 2017, there were a handful of resolvers using this protocol and the announcements of trust anchors showed a higher percentage of misconfigured trust anchors than initially anticipated. However, the signal observed at the time was not well understood and, as a result, the ICANN org decided to postpone the root zone KSK roll to better understand the signal with the help of the technical community. Further research by the ICANN org's Office of the CTO (OCTO) team and others revealed concerns with the quality of the RFC 8145 data. For example, a DNS query reporting trust anchor information that is sent to a forwarder is treated the same as any other query and will be sent to a root server regardless if the forwarder is validating or not. In one case, a popular DNS resolver implementation signaled the trust anchor even though the resolver was not configured to validate and thus would not have the new trust anchor. This implementation decision was reversed in a subsequent release of the software. In another case, a well-known DNS resolver library signaled the trust anchor but did not have a method to automatically update its trust anchor configuration. As a result, a single deployment of a popular single-user VPN implementation using that DNS resolver library would emit the old trust anchor signal from different source addresses over time. Wes Hardaker at the University of Southern California Information Sciences Institute discovered this behavior and the vendor using the library was informed and updated their software. This change has significantly reduced the number of sources reporting the old trust anchor.4 However, the RFC 8145 data reports only resolvers; it does not provide an indication of the number of end users dependent upon those resolvers. To understand the size of the population of users behind validating resolvers, the Regional Internet Registry for the Asia Pacific region (APNIC) used a measurement system that utilizes Google's advertising network to query the DNS. Analyzing the intersection of ICANN's trust anchor signaling sources with their own resolver sources and then extrapolating, APNIC calculated that only 0.05 percent of Internet users would be negatively affected by the root KSK roll.5 Looking forward, the ICANN org will soon reach out to the 1,000 Internet Service Providers (ISPs) with the most active resolver traffic that suggests DNSSEC validation has been enabled in order to ensure they aware that the root KSK roll will occur on 11 October 2018. Those ISPs will also be surveyed on their preparation plans for the rollover, which may cause those resolver operators to become more aware of the KSK rollover. Since the first announcement of the development of plans to roll the trust anchor in 2015, the ICANN org has maintained an outreach campaign that has (to date) included nearly 100 speaking engagements at international, regional, and national conferences, and more than 150 news stories in the technical press. The ICANN org has also published nine blog articles related to the trust anchor rollover and continues to reach out to the ISPs that have validating resolvers in their networks but which, from RFC 8145 data, do not appear to have the new trust anchor configured. As a result of these efforts and the data we have been able to collect, the ICANN org has increased confidence that the root KSK rollover planned for 11 October 2018 will have the potential to affect only a tiny fraction of DNS users. 1 https://www.iana.org/dnssec/icann-dps.txt 2 https://datatracker.ietf.org/doc/rfc5011/ 3 https://datatracker.ietf.org/doc/rfc8145/ 4 http://root-trust-anchor-reports.research.icann.org/ 5 http://www.potaroo.net/ispcol/2018-04/ksk.pdf [PDF, 184 KB […]

  • A Review of Our FY18 Middle East Journey
    on July 18, 2018 at 7:00 am

    The year was filled with accomplishments as well as challenges for ICANN in the Middle East. As we build upon our accomplishments and learn from the challenges, we take this opportunity to present a report on our regional activities. But before doing so, we'd like to thank each of our community members in the Middle East for their tireless efforts and collaboration, leading us to where we are now, with a bright future of ICANN activities in the region. The report is built upon ICANN's Middle East Global Stakeholder Engagement (GSE) team activities in FY18, with a focus on building capacity and raising awareness around ICANN and the wider Internet ecosystem. The report highlights include: Regional participation rates at ICANN Public Meetings Regional events, webinars, and workshops Academic engagements Regional studies Community feedback The report also includes ICANN regional community member and participant surveys to assess the efficiency of our efforts in the region. Among them is a survey on ICANN's FY18 Middle East Engagement. To see the results of this survey, click here [PDF, 111 KB]. You can review the full report here [PDF, 878 KB], and contact us at meac.swg@icann.org for feedback or questions. […]

  • Enforcing the Temporary Specification
    on July 16, 2018 at 7:00 am

    In May, the ICANN Board adopted the Temporary Specification for gTLD Registration Data, modifying our agreements with registries and registrars to comply with the European Union's General Data Protection Regulation (GDPR). Since then, ICANN Contractual Compliance has received a number of questions regarding how we would enforce these new provisions. The purpose of this blog is to describe our approach to enforcing the Temporary Specification, explain how to file complaints about potential violations of the new provisions, and share information on some of the issues we have seen so far. As noted at the Global Domains Division (GDD) Industry Summit in May and at the ICANN62 Policy Forum in June, ICANN Contractual Compliance is enforcing the requirements of the Temporary Specification as of 25 May 2018, as it does any other ICANN agreement or policy requirement. This is done through the Contractual Compliance function, which employs the same approach and process for all enforcement areas. Details regarding this approach and process can be found here. All contracted parties are advised to review the Temporary Specification carefully. Many of the requirements apply even if the registry or registrar is not in the European Union and has no registrations from the European Economic Area. Enforcement of the Temporary Specification applies to all ICANN contracted parties. For a high level review of the Temporary Specification, ICANN also published and regularly updates a Frequently Asked Questions document. One recurring concern we have received is how ICANN Contractual Compliance will obtain non-public registration data that is required to process a complaint. Among the complaints received to date, ICANN Contractual Compliance has received two alleging denial of access to non-public registration data for legitimate purposes. Most of the other complaints received concern the availability of data published in WHOIS. For registrars, some of the registration data issues include: Over-redacting public registration data, e.g.: All contact fields are redacted when only some should be; Missing Administrative/Technical email field and/or value; Missing Registrant Organization/State/Province/Country field and/or value; and Redacting privacy/proxy information Non-compliant redacted fields e.g., missing anonymized email and/or webform to contact Registrant/Admin/Tech contact or using non-compliant values in the field for ex. "00000" Registrar appears to be using registry WHOIS data causing endless loop of referral from registry to registrar data Transfer requests being denied due to non-functional anonymized email address for registrant Some of the registry issues include: Missing required Registrant/Admin/Tech Email (requirement for registries) Required Registrant/Admin/Tech Email message in legal disclaimer only Not providing full registration data to the Uniform Rapid Suspension System (URS) provider Registry providing thick Bulk Registration Data Access (BRDA) files to ICANN instead of thin data We have also received a number of questions regarding the process for filing complaints alleging noncompliance with the Temporary Specification. As many have observed, there is not a "Temporary Specification" complaint form. To file a complaint about potential violations of the Temporary Specification or any other part of the agreements, please use the most relevant form published on the ICANN.org compliance page. ICANN Contractual Compliance will process complaints regardless of the form used. I hope this information is helpful. If you have any other questions or concerns regarding enforcement of the Temporary Specification, please let us know by emailing either the Contractual Compliance department at compliance@icann.org or me at Jamie.hedlund@icann.org. […]

  • Data Protection/Privacy Update: Additional Guidance from the European Data Protection Board
    on July 13, 2018 at 7:00 am

    The ICANN community has been engaged in focused discussion and engagement about the impact of the European Union's General Data Protection Regulation (GDPR) on the WHOIS system over the past year. During this time, ICANN org worked with the community to develop an interim approach for how ICANN and gTLD registries and registrars could continue to comply with ICANN agreements in relation to the GDPR. This interim solution was adopted by the ICANN Board in May 2018 as the Temporary Specification for gTLD Registration Data. The community continued discussions during ICANN's recent meeting in Panama (ICANN62), which included discussions about initiating policy development work for a long-term solution, as well as a possible unified approach to allow continued access to full WHOIS data to third-parties with a legitimate interest. You can find key updates, documents, legal analyses, guidance from European data protection authorities, and inputs from the community about this topic on our Data Protection/Privacy Issues webpage. An important letter [PDF, 764 KB] of note, was received by ICANN on 5 July 2018, from the European Data Protection Board (EDPB) which provided additional guidance that may help significantly to advance the ICANN community's discussion on this important issue. We are very grateful to the EDPB for its guidance and willingness to engage with ICANN.  We are carefully evaluating the additional guidance concerning our compliance with the GDPR, as it relates to publication and access to personal data which is processed in the context of ICANN's coordination of the WHOIS through its contracts with its 2,500 domain name registries and registrars. This blog will address what we are looking at from the letter and why we think the guidance is so important. Below I will highlight some of the key points in the letter and share our initial thinking about possible options for incorporating this guidance into WHOIS in the coming weeks and months. The EDPB's letter provides answers to some of the open questions from ICANN and the ICANN community relating to ICANN's approach in the Temporary Specification. A good example, on a specific open question concerning registrations of legal persons and whether such registrations are impacted by the GDPR, the EDPB advises that it "considers that personal data identifying individual employees (or third parties) acting on behalf of the registrant should not be made publically available by default in the context of WHOIS. If, on the other hand, the registrant provides generic contact email information (e.g. admin@domain.com), the EDPB does not consider that the publication of such data in the context of WHOIS would be unlawful…." Second, the EDPB's letter provides important guidance to advance recent community discussions about a unified access model for how legitimate users of WHOIS data could continue to have access to non-public data. The EDPB notes that non-public WHOIS data could be made available to third parties "provided that appropriate safeguards are in place to ensure that the disclosure is proportionate and limited to that which is necessary and the other requirements of the GDPR are met…." The EDPB confirms its expectation of ICANN developing "a WHOIS model which will enable legitimate uses by relevant stakeholders, such as law enforcement…" This is a strong indicator that we will receive additional inputs were the community to continue its work and come together to identify a method providing access to non-public WHOIS data consistent with the law. The EDPB letter provides helpful insight into transparency requirements that should be part of a model, including appropriate logging of data requests, as well helpful suggestions in the event ICANN is considering a model that uses codes of conduct and accreditation as the approach to providing access to the data. Third, the EDPB highlights some areas where ICANN may provide additional clarity about GDPR compliance as it relates to the global WHOIS system. The areas identified by the EDPB relate to ICANN's purposes for processing gTLD registration data, data collection, as well as the appropriate period for retaining personal data.  Last, the EDPB letter makes reference to ICANN's ongoing legal proceedings in Germany against the registrar EPAG, with specific references to the clarifications ICANN provided in its court filings concerning administrative and technical contact details that are collected as part of a WHOIS record. Because of this reference, earlier this week, ICANN submitted the EDPB's letter to the court for its consideration. A copy of this submission will be published on our Litigation Documents webpage. We are carefully considering the guidance provided by the EDPB to inform the ICANN Board whether clarifications, changes or implementation adjustments may be needed to the Temporary Specification adopted on 17 May 2018. We also are evaluating this guidance as it relates to the Framework Elements for a Unified Access Model, possible contractual compliance actions against contracted parties, as well as the ongoing legal proceedings in Germany where ICANN asked the Regional Court in Bonn for assistance in interpreting the GDPR in order to protect the data collected in WHOIS. We would encourage the community to read the full of the EDPB letter, share your thoughts and continue to participate in discussions we will have over the coming months. We also hope that the EDPB's guidance will be a helpful input to the important policy work being conducted in the expedited policy development process that is being initiated by the GNSO Council. We look forward to continuing to work with you, and we are hopeful that we can continue the progress of the collective ICANN community on these important issues. We will continue to keep the community apprised of developments, and please also see our Data Protection/Privacy and provide any input through gdpr@icann.org. […]

  • FY19 Community Regional Outreach Program (CROP) Ready for Use by Eligible ICANN Communities
    on July 3, 2018 at 7:00 am

    The Global Stakeholder Engagement (GSE) and Policy teams are pleased to report that the Community Regional Outreach Program (CROP) FY19 is ready for the ICANN community to use as of 3 July 2018. Following community consultations and Public Comments on the Draft FY19 Operating Plan and Budget, the ICANN Board allocated USD 50,000 for CROP in the final FY19 budget. To ensure that support for community outreach efforts remains within the appropriate budget framework while balancing the program goals, the ICANN organization was directed to review the existing CROP guidelines and develop improved, additional criteria for FY19. The ICANN org has also been tasked with assessing the CROP process at the end of FY19. The final FY19 CROP guidelines are consistent with the other community travel and outreach programs that the ICANN org administers. Accordingly, the fundamental principle is that CROP funding is to be used for FY19 outreach efforts that are directly and demonstrably related to ongoing ICANN policy, technical, and advisory activities, in accordance with the new CROP guidelines and additional specific criteria. The new CROP allocates up to three regional trips to each of the five Regional At-Large Organizations (RALOs) and each eligible constituency in the Generic Names Supporting Organization (GNSO) – Business Constituency (BC), Intellectual Property Constituency (IPC), Internet Service Providers and Connectivity Providers Constituency (ISPCP), Non-Commercial Users Constituency (NCUC), and Not-for-Profit Operational Concerns Constituency (NPOC). With a few specific exceptions as detailed in the new guidelines, these allocations are to be used mainly for outreach activities at ICANN Public Meetings in the relevant region or official regional meetings organized by the ICANN org. As was previously the case, each eligible community group must have in place a relevant outreach strategic plan. Under the new CROP guidelines, the plan must address certain specific additional requirements. As before, trip requests need to be submitted at least six weeks prior to travel dates. In addition, the relevant regional GSE vice president must approve the request at least five working days before the six-week travel deadline. We invite you to browse through the CROP FY19 space and the CROP Procedures and Guidelines page to familiarize yourself with the updated program. Please watch for the CROP team announcement on your community mailing lists. This announcement will give more details about how to coordinate with CROP team to begin using the program. We are pleased to be able to continue to support the community's regional outreach activities for FY19. We look forward to your feedback at the end of this fiscal year so that we may continue to improve the program in line with the community's budgeting priorities in future years. […]

ICANN Announcements

ICANN Announcements ICANN Announcements

  • 2018 Nominating Committee Update on Candidate Selections
    on July 17, 2018 at 7:00 am

    LOS ANGELES – 17 July 2018 – The 2018 Nominating Committee (NomCom) is pleased to announce that the selection of all 2018 open ICANN leadership positions was finalized by the Committee at ICANN62 in Panama City, Panama. The selections for the three ICANN Board positions were decided unanimously. The ICANN organization has sent out communications to the successful candidates and any alternates, as well as to those who made it to the final round but were not selected this year. The NomCom plans to make a public announcement of the successful candidates in August 2018. The 2018 NomCom would like to thank the Board, Advisory Committees, Supporting Organizations, stakeholder groups, and constituencies for their support with outreach and recruitment, as well as their assistance in outlining requested criteria for the open positions. The NomCom encourages the ICANN community to continue its assistance in recruiting candidates for the 2019 NomCom. For more information on the 2018 NomCom, including timeline and work phases, please visit https://www.icann.org/nomcom2018. […]

  • Successful Candidates Announced for ICANN63 Fellowship
    on July 16, 2018 at 7:00 am

    LOS ANGELES – 16 July 2018 - The Internet Corporation for Assigned Names and Numbers (ICANN) organization is pleased to announce the 45 individuals from 39 countries that have been selected to participate in the ICANN Fellowship Program at ICANN63 Annual General in Barcelona, Spain, from 20-25 October 2018. The successful candidates represent all sectors of society including, civil, government, ccTLD operations, academia, business community, technical, security, and end user groups. The Fellowship Program seeks out individuals who are interested in, or already engaged in, the various aspects of ICANN's work in policy building, the operation of the Domain Name System, and the security and stability of the global Internet. The goal of the program is to help create a broader and more diverse base of knowledgeable constituents. Priority is given to candidates currently living in underserved and underrepresented communities around the world, representing diversity of gender, sector, region, experience, expertise, and financial need. The ICANN org received a total of 471 applications for the ICANN63 Fellowship Program. Click this link to see the list of selected candidates and to learn more about the Fellowship Program. About ICANN ICANN’s mission is to help ensure a stable, secure, and unified global Internet. To reach another person on the Internet, you need to type an address – a name or a number – into your computer or other device. That address must be unique so computers know where to find each other. ICANN helps coordinate and support these unique identifiers across the world. ICANN was formed in 1998 as a not-for-profit public-benefit corporation with a community of participants from all over the world. […]

  • ICANN Board of Directors Submits Comments Regarding NTIA's Notice of Inquiry on International Internet Policy Priorities
    on July 13, 2018 at 7:00 am

    LOS ANGELES – 13 July 2018 – The Board of Directors of the Internet Corporation for Assigned Names and Numbers (ICANN) submitted comments [PDF, 320 KB] today in response to the United States Department of Commerce National Telecommunications and Information Administration (NTIA) Notice of Inquiry (NOI) on International Internet Policy Priorities. In its comments, ICANN's Board of Directors highlighted the success of the multistakeholder model and enhancements made to the organization's accountability mechanisms during the IANA stewardship transition. The comments also pointed to the high customer satisfaction levels delivered by the operator of the Internet Assigned Numbers Authority (IANA) functions, Public Technical Identifiers (PTI). For more information about the NTIA's NOI, please visit https://www.ntia.doc.gov/federal-register-notice/2018/notice-inquiry-international-internet-policy-priorities. About ICANN ICANN's mission is to help ensure a stable, secure and unified global Internet. To reach another person on the Internet, you need to type an address – a name or a number – into your computer or other device. That address must be unique so computers know where to find each other. ICANN helps coordinate and support these unique identifiers across the world. ICANN was formed in 1998 as a not-for-profit public-benefit corporation with a community of participants from all over the world. […]

  • Root Server System Advisory Committee Review: Final Report Now Available
    on July 10, 2018 at 7:00 am

    LOS ANGELES – 10 July 2018 – Today, Interisle Consulting Group, LLC, the independent examiner performing the second Root Server System Advisory Committee (RSSAC) Review, published its final report. Read the report [PDF, 2.58 MB]. The final report includes an assessment of the RSSAC with eight principal findings and six principal recommendations for improving its operations. The recommendations focus on RSSAC purpose, effectiveness, and accountability. The final report published today considers comments on the draft final report published on 1 May 2018, input provided during the public webinar on 9 May 2018 and any other feedback Interisle may have received. Next Steps The RSSAC Review Work Party (RWP) will prepare a feasibility assessment and initial implementation plan (FAIIP) based on the final report. This will include an analysis of recommendations in the final report for usability and prioritization, provisional budget implications, anticipated resources and the proposed implementation timeline. Interisle and the RWP respectively will then present the final report and the FAIIP to the ICANN Board's Organizational Effectiveness Committee (OEC). The OEC will make a recommendation to the Board on next steps. Background An independent review of the RSSAC is mandated by ICANN's Bylaws and is part of ICANN's commitment to its own evolution and improvement, accountability and transparency. Interisle was selected to perform the review and began its work in September 2017. The purpose of the RSSAC review, according to the Bylaws, is to determine (i) whether the RSSAC has a continuing purpose in the ICANN structure, (ii) if so, whether any change in structure or operations is desirable to improve its effectiveness and (iii) whether the RSSAC is accountable to its constituencies, stakeholder groups, organizations and other stakeholders. The review also includes an assessment of the implementation state of RSSAC's prior review [PDF, 234 KB]. Additional Resources Visit the RSSAC Review wiki and the RSSAC Review page on ICANN.org for more information and resources related to the review. Visit the RSSAC page on ICANN.org to learn more about the RSSAC. About ICANN ICANN's mission is to help ensure a stable, secure and unified global Internet. To reach another person on the Internet, you need to type an address – a name or a number – into your computer or other device. That address must be unique so computers know where to find each other. ICANN helps coordinate and support these unique identifiers across the world. ICANN was formed in 1998 as a not-for-profit public-benefit corporation with a community of participants from all over the world. […]

  • Initial Report on the New gTLD Subsequent Procedures Policy Development Process (Overarching Issues & Work Tracks 1-4)
    on July 3, 2018 at 7:00 am

    Open Date: 03 July 2018 Close Date: 05 September 2018 Originating Organization: GNSO Categories/Tags: Policy Development Brief Overview: This public comment proceeding seeks to obtain input on the Initial Report of the New gTLD Subsequent Procedures Policy Development Process Working Group, which is chartered to evaluate what changes or additions need to be made to existing new gTLD policy recommendations. The document includes materials from the full Working Group and four sub-teams within the Working Group, Work Tracks 1-4. Work Track 5, focused on Geographic Names and the Top-Level, will produce a separate Initial Report. Link: https://www.icann.org/public-comments/gtld-subsequent-procedures-initial-2018-07-03-en […]