Tag Archives: Registrar Accreditation Agreement

German Courts Rebuff ICANN For Fourth Time Over WHOIS/GDPR Data Collection

ICANN has suffered another setback in its desire to continue to collect and make public domain name registrant contact details following an appeal to a German High Court who ruled against ICANN's plea to reconsider the Court's own earlier decision following the introduction of the European Union's General Data Protection Regulation earlier this year.

ICANN has been pursuing a preliminary injunction from the German Court to require EPAG, a Germany-based, ICANN-accredited registrar (that is part of the Tucows Group and based in Bonn, Germany) to continue to collect elements of WHOIS data, as required under ICANN's Registrar Accreditation Agreement (RAA), which permits the registrar to sell domain name registrations for generic top-level domains.

ICANN received a ruling from the German Higher Regional Court in Cologne (“Appellate Court”) last week, that rejected ICANN's request for review (“plea of remonstrance”) filed by ICANN on 17 August 2018. ICANN's plea was filed to continue the immediate appeal in the ICANN v. EPAG injunction proceedings. ICANN initiated such proceedings against EPAG, to seek assistance in interpreting the European Union's General Data Protection Regulation (GDPR) in order to protect the data collected in WHOIS. The Appellate Court again has determined that it would not issue an injunction against EPAG.

This is the fourth time the German courts have rebuffed ICANN’s attempts to have EPAG enforce the RAA. On 30 May the Regional Court determined that it would not issue an injunction against EPAG. Then on 13 June ICANN appealed and on 18 July the Regional Court decided not to change its original determination not to issue an injunction against EPAG. The matter was referred to the Higher Regional Court in Cologne for appeal. Next on 3 August ICANN announced a German appeal court (Appellate Court of Cologne) had issued a decision on the injunction proceedings ICANN initiated against EPAG determining that it would not issue an injunction against EPAG.

In making its ruling, the Appellate Court found that the preliminary injunction proceeding does not provide the appropriate framework for addressing the nature of the contractual disputes at issue, and that a decision in preliminary proceedings does not appear to be urgently needed. Again, the Appellate Court did not address the merits of the underlying issues with respect to the application of GDPR as it relates to WHOIS.

ICANN is continuing to evaluate its next steps in light of this ruling, including possible additional filings before the German courts, as part of its public interest role in coordinating a decentralized global WHOIS for the generic top-level domain system.

On 25 May, the day the European Union’s General Data Protection Regulation came into place, ICANN filed a legal action against EPAG. This action was taken because of a disagreement between Tucows and ICANN on how the GDPR should be interpreted, with respect to their contracts.

In a post outlining their position back in May, EPAG Ashley La Bolle wrote the “GDPR begins with a statement of its core principle: ‘The protection of natural persons in relation to the processing of personal data is a fundamental right.’ Tucows has long been concerned with privacy and the rights of our customers, and takes the principles enshrined in this law extremely seriously.

“In order to have a domain registration system reflective of ‘data protection by design and default’, we started with the GDPR itself and crafted our procedures and policies around it. We built a new registration system with consent management processes, and a data flow that aligns with the GDPR’s principles. Throughout the registration life-cycle, we considered things like transparency, accountability, storage limitation, and data minimization.”

ICANN’s response to the GDPR came just over a week before the EU-wide data protection regulation came into place, and 2 years after it was announced. The “Temporary Specification”, as La Bolle writes, was “meant to temporarily bring gTLD registration services in line with the GDPR. The goal of the Specification is to serve as a stop-gap while the ICANN community works to resolve and balance issues between privacy law and existing ICANN policy.” EPAG have 3 concerns with the Temporary Specification based around “Personal Data Transfer to a Registry”, “Personal Data Display” and “Desire for Clarity”.

Request for Proposal: ICANN’s Technical Compliance Monitoring System

ICANN logoICANN is seeking to identify a provider to develop and maintain a Technical Compliance Monitoring system. The Technical Compliance Monitoring system is intended to enable the ICANN org to help generic top-level domain (gTLD) registries and registrars ensure compliance with ICANN‘s consensus policies, as well as the provisions described in the 2017 gTLD Base Registry Agreement and the 2013 Registrar Accreditation Agreement (contracted parties’ agreements).

This system will allow the ICANN org to operate more efficiently and engage parties in a consistent, transparent manner for issues related to compliance with the contracted parties’ agreements.

The objective of the system is to automate the monitoring of compliance to approximately 80 provisions in the contracted parties’ agreements and consensus policies (in addition to other already existing systems and processes). The system is intended to pull information from internal and external data sources, check compliance with relevant provisions, and push results to a central repository.

ICANN is seeking to identify a provider to develop this system based on ICANN‘s requirements, as well as to maintain the system and develop additional enhancements.

For a complete overview of the RFP including the timeline, please see here [PDF, 259 KB].

Indications of interest should be emailed to TechnicalComplianceMonitoring-RFP@icann.org. Proposals should be electronically submitted by 23:59 on 04 December 2017 UTC using ICANN‘s sourcing tool. Access to the ICANN org sourcing tool may be requested via the same email.

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.

This ICANN announcement was sourced from:
https://www.icann.org/news/announcement-2017-11-06-en

ICANN: Call for Participation – Privacy & Proxy Services Accreditation Issues Policy Development Process Implementation Review Team

ICANN logoOn 9 August 2016, the ICANN Board of Directors adopted the recommendations of the Privacy & Proxy Services Accreditation Issues Policy Development Process (PDP) Working Group as listed in its Final Report [PDF, 1.23 MB].

Staff from the Global Domains Division (GDD)—responsible for leading the implementation of the policy recommendations—is hereby issuing a call for volunteers to form an Implementation Review Team (IRT) to work with staff to implement the policy recommendations adopted by the Board.

This call for IRT volunteers is for the attention of the members of the Privacy & Proxy Services Accreditation Issues PDP Working Group at a minimum. However, other members of the community who did not participate on the IRT are also invited to the IRT. The key responsibilities of the IRT are as follows:

  • Work with ICANN staff to ensure that the implementation fulfills the original intentions of the adopted policy recommendations
  • Review the proposed implementation work plan, as drafted by staff, for the recommendations as adopted by the Board
  • Assist in case questions regarding the PDP or a need for clarification arises in relation to the adopted recommendations
  • Advise on technical and operational details related to the implementation of the adopted recommendations

Familiarity with the policy recommendations as well as the deliberations that informed those recommendations is a minimum requirement for IRT members. IRT volunteers should be able to attend regularly scheduled IRT meetings for the duration of this project. Staff currently anticipates that this implementation project could take up to 18-24 months to complete.

All volunteers responding to this call will be expected to understand the role and remit of the IRT for the implementation project. If, in the course of implementation, the IRT identifies a need for potential modifications to the policy recommendations, the team must refer these to the GNSO Council for its consideration and additional guidance.

How to Apply

If you are interested in participating, please send an email to the GNSO Secretariat via gnso-secs@icann.org no later than 30 September 2016, 11:59 UTC.

Background

The Registrar Accreditation Agreement (RAA) is the contract that governs the relationship between ICANN and its accredited registrars (a directory of accredited registrars can be found at http://www.internic.net/regist.html). The RAA also may have impacts on registrants and other third parties involved in the domain name system.

In initiating negotiations for the 2013 RAA between ICANN and the Registrars Stakeholder Group in October 2011, the ICANN Board had also requested an Issue Report from the GNSO that would start a GNSO Policy Development Process (PDP) to address remaining issues not dealt with in the RAA negotiations and that would be suited to a PDP (the Board’s Resolution can be found at http://www.icann.org/en/groups/board/documents/resolutions-28oct11-en.htm#7). In June 2013, the ICANN Board approved a new 2013 RAA (the provisions of which can be found at http://www.icann.org/en/resources/registrars/raa/approved-with-specs-27jun13-en.pdf) [PDF, 913 KB], and this PDP was launched in October 2013.

The Final Recommendations of the Privacy & Proxy Services Accreditation Issues PDP Working Group, which GDD is now preparing to implement, are the consensus outcomes of that PDP. Once implemented, this Privacy and Proxy Services accreditation program will supersede requirements in the 2013 RAA‘s Specification on Privacy and Proxy Registrations.

This ICANN announcement was sourced from:
https://www.icann.org/news/announcement-2016-09-19-en

ICANN’s Corporate Responsibility to Respect Human Rights by Monika Zalnieriute

Social Science Research Network logoAbstract: Freedom of expression and privacy are internationally recognised human rights. This paper addresses the privacy and freedom of expression issues that arise in relation to ICANN policies and procedures.

In particular, it explores the corporate responsibility of ICANN to respect human rights. It relies on the UN Guiding Principles on Business and Human Rights (Guiding Principles), known as the ‘Protect, Respect, and Remedy’ framework,ii which were unanimously adopted by the United Nations Human Rights Council in June 2011.

This paper sets out the UN Guiding Principles and explains their relevance to ICANN’s policies and procedures on new gTLDs and the Registrar Accreditation Agreement (RAA). In particular, it examines the ways in which ICANN’s standards and policies governing the ‘sensitive applied-for strings’ fall short of freedom of expression standards, and, furthermore, how the RAA provisions are in breach of data protection best practices and standards.

This paper is available for download in full from the Social Science Research Network website at:
ssrn.com/abstract=2667488

ICANN: Advisory Concerning Registrar Obligations to Provide Data to ICANN Pursuant to Section 3.4.3 of the 2013 RAA

ICANN logoSection 3.4.3 of the 2013 Registrar Accreditation Agreement (the “2013 RAA“) requires registrars to provide certain data, information, and records to ICANN upon request and incorporates a procedure by which ICANN and registrars can agree to limitations, protections, or alternative solutions in the event a registrar believes that the provision of such data to ICANN would violate applicable law or legal proceedings.

Several registrars have requested clarification from ICANN regarding the 2013 RAA‘s procedure for discussing and agreeing on appropriate limitations, protections, or alternative solutions for production of data, information, or records requested by ICANN. In particular, registrars have told ICANN that meaningful discussions of potentially relevant legal issues require that ICANN identify

(i) the purposes for which ICANN is requesting such data, information, or records;
(ii) how ICANN intends to use such data, information, or records; and
(iii) duration for which ICANN intends to retain such data, information, or records.1

The following advisory outlines the relevant provisions of the 2013 RAA and explains the steps that ICANN will take upon a registrar’s request if ICANN seeks access to data, information, or records pursuant to Section 3.4.3 of the 2013 RAA.

Relevant Provisions of the 2013 RAA

Section 3.4.3 of the 2013 RAA provides:

3.4.3  During the Term of this Agreement and for two (2) years thereafter, Registrar shall make the data, information and records specified in this Section 3.4 available for inspection and copying by ICANN upon reasonable notice. In addition, upon reasonable notice and request from ICANN, Registrar shall deliver copies of such data, information and records to ICANN in respect to limited transactions or circumstances that may be the subject of a compliance-related inquiry; provided, however, that such obligation shall not apply to requests for copies of the Registrar’s entire database or transaction history. Such copies are to be provided at Registrar’s expense. In responding to ICANN‘s request for delivery of electronic data, information and records, Registrar may submit such information in a format reasonably convenient to Registrar and acceptable to ICANN so as to minimize disruption to the Registrar’s business. In the event Registrar believes that the provision of any such data, information or records to ICANN would violate applicable law or any legal proceedings, ICANN and Registrar agree to discuss in good faith whether appropriate limitations, protections, or alternative solutions can be identified to allow the production of such data, information or records in complete or redacted form, as appropriate. ICANN shall not disclose the content of such data, information or records except as expressly required by applicable law, any legal proceeding or Specification or Policy.

Procedure for Data To Be Made Available to ICANN

  1. If, pursuant to Section 3.4.3, ICANN provides notice to a registrar requiring that (1) data, information, or records be made available to ICANN for inspection or copying; or (2) that data, information or records be delivered to ICANN, the registrar may request, in writing (with email deemed sufficient), that ICANN provide a written description specifying to a reasonable extent: (a) the data, information, and records that are the subject of the request; and (b) the purpose, including identification of the transfers envisaged to third parties and the purpose of such transfer, for which ICANN maintains that access to or a copy of the data, information, and records is necessary (the “Access Purpose Description”).
  2. ICANN will, upon the written request of the registrar, provide the registrar with the Access Purpose Description in writing (with email deemed sufficient).  With respect to the purpose, ICANN is limited to one or more of the purposes described in the draft document “Description of 2013 RAA Data Retention Specification data elements and potentially legitimate purposes for collection/retention” that was posted on 21 March 2014 (the “Description”) as it may be modified by ICANN from time to time.  Any future changes to the Description must be in line with the law and regulations applicable to the registrars, including but not limited to rules on the processing of data for purposes which are not incompatible with the legitimate purpose for which the data were originally collected.  ICANN will work in good faith to agree with the Registrar on appropriate levels of data protection, if applicable, and, respecting any safeguards necessary to achieve this purpose (e.g., Standard Contractual Clauses, if appropriate).
  3. If an Access Purpose Description is requested by a registrar and provided by ICANN, ICANN will not process or use the data, information, and records for any purpose other than those stated in the Access Purpose Description. This does not exclude ICANN from issuing a further Access Purpose Description, referring to one or more purposes listed in the Description, if another purpose becomes relevant with respect to such data, information, and records and is in line with the law and regulations applicable to the registrars, including but not limited to rules on the processing of data for purposes which are not incompatible with the legitimate purpose for which the data were originally collected. As provided in Section 3.4.3 of the 2013 RAA, ICANN will not disclose the content of such data, information, or records to a third party except as expressly required by applicable law; any legal proceeding; or Specification or Policy (as defined in the 2013 RAA) in line with the law and regulations applicable to the registrars, including but not limited to rules on the processing of data for purposes which are not incompatible with the legitimate purpose for which the data were originally collected; and, to the extent applicable, in line with any “onward transfer requirements” safeguards to which ICANN has stipulated to ensure appropriate levels of data protection on part of ICANN (e.g.,  Standard Contractual Clauses, if appropriate). If ICANN is required to disclose the content of the data, information or records in accordance with the preceding sentence, it will immediately notify the registrar involved in writing (with email deemed sufficient) of the grounds for the order or requirement, the party to whom the data must be disclosed and the stated purpose of the disclosure, as well as the legal means available to oppose such disclosure, if and to the extent stated in the order or requirement, unless and to the extent such notification is expressly prohibited by law or court order.
  4. ICANN will delete the data, information, and records if and when they are no longer required for the purpose(s) stated in the Access Purpose Description(s), subject to adherence to any retention requirements mandated by law, if any.

If a registrar believes that the provision of any such data, information, or records to ICANN would violate applicable law or any legal proceedings, any ensuing good faith discussions between ICANN and the registrar will take into consideration the purposes set forth in the Access Purpose Description provided by ICANN.  In those good faith discussions, ICANN would take into account, without limitation any legal opinion submitted by the registrar from a nationally recognized law firm in the applicable jurisdiction and, in particular, the rulings or guidance provided by a national or EU governmental body of competent jurisdiction including relevant data protection authorities, as well as the requirement of Section 3.7.2 2013 RAA that registrar shall abide by applicable laws and governmental regulations.

If good faith discussions are ongoing between ICANN and the registrar as indicated above, ICANN would refrain from commencing a compliance procedure against the registrar for breach of Section 3.4.3 of the 2013 RAA for a reasonable period of time with the goal of allowing the good faith discussions to facilitate a resolution.


1In discussions with ICANN, most registrars have acknowledged that legitimate purposes exist for the retention of the data elements specified in Articles 1.1 and 1.2 of the Data Retention Specification (the “Specification”) of 2013 RAA, but some registrars have called for clarification of the 2013 RAA‘s process for ICANN‘s request for data from a registrar to ensure a compatible use of the data, which is not addressed by the waiver process described in the Specification.

ICANN announcement was sourced from:
https://www.icann.org/news/announcement-2015-06-05-en

ICANN: 2013 RAA Whois Accuracy Program Specification Review

ICANN logoPurpose (Brief): The purpose of this initiative is to review the 2013 Registrar Accreditation Agreement’s Whois Accuracy Program Specification.

Public Comment Box Link: https://www.icann.org/public-comments/2013-whois-accuracy-spec-review-2015-05-14-en

Comment Period Opens on 14 May 2015

This ICANN announcement was sourced from:
https://www.icann.org/news/announcement-2015-05-14-en

ICANN Grants Data Retention To French And German Registrars

ICANN logoICANN announced yesterday it has granted four more data retention waivers to registrars domiciled in France and Germany due to their inability to sign ICANN’s 2013 Registrar Accreditation Agreement.

The registrars involved were ingenit GmbH & Co. KG, 1API GmbH, RegistryGate GmbH (all German) and MAILCLUB SAS (French). For all three, as with other requests, there were legitimate concerns that they would violate data retention laws in their countries.

In the case of MAILCLUB, ICANN noted that “pursuant to Section 3 of the Data Retention Specification of the 2013 RAA, which provides that if a registrar is subject to the same applicable law that gave rise to ICANN’s request to grant a previous data retention waiver under the 2013 RAA, a registrar may request that ICANN grant a similar waiver, which request shall be approved by ICANN, unless ICANN provides Registrar with a reasonable justification for not approving such request.” ICANN “determined that it is appropriate to grant Registrar a data retention waiver similar to the waiver previously granted to OVH SAS.”

Registrar’s Waiver Request cites the previous data retention waiver granted by ICANN to OVH SAS, on the basis of OVH SAS’s contention that compliance with the data collection and/or retention requirements of the Data Retention Specification in the 2013 RAA violates applicable law in France.

In the announcement, ICANN agreed “that following Registrar’s execution of the 2013 RAA, for purposes of assessing Registrar’s compliance with the data retention requirement of Paragraph 1.1 of the Data Retention Specification in the 2013 RAA, the period of ‘two additional years’ in Paragraph 1.1 of the Data Retention Specification will be deemed modified to ‘one additional year.’”

For the German registrars, ICANN noted that “shall remain obliged to retain all data elements specified in Articles 1.1.1 through 1.1.8 of the Specification for the duration of its sponsorship of the Registration and for a period of two (2) additional years thereafter; however, Registrar will be permitted to block the data elements specified in Articles 1.1.1 through 1.1.8 of the Specification in accordance with blocking requirements under applicable law (see Sec. 35 para. 3 German Federal Data Protection Act (Bundesdatenschutzgesetz – BDSG) at the earliest after one year following the end of the Registrar’s sponsorship of the Registration, provided that the rights of data subjects under Sec. 35 para 2 second sentence BDSG shall remain unaffected.”

There are also changes regarding Articles 1.2.1, 1.2.2 and 1.2.3 in the ICANN announcements for the German registrars.

In relation to the German requests, ICANN noted “that the provisions of Section 3 of the Specification will apply to similar waivers requested by other registrars that are located in Germany and subject to German law.” So it can be expected there will be further requests from registrars required to sign the 2013 Registrar Accreditation Agreement.

ICANN: Request for Information on Contact Data Validation and Verification Systems

ICANN logoICANN is publishing a Request for Information (RFI) [PDF, 395 KB] to identify any commercially-available services and software that might be capable of validating or verifying domain name registration contact data (such as WHOIS).

This RFI is intended to inform two distinct ICANN projects that require address validation and verification. The first project relates to a near-term need for postal address cross-field validation services arising out of requirements applicable to those registrars who have signed the new 2013 Registrar Accreditation Agreement (RAA Project).

In addition, ICANN is seeking similar information for a separate longer term project in connection with Expert Working Group on Next Generation gTLD Directory Services (“EWG”) recommendations to identify a replacement to the current WHOIS system. The EWG is now developing recommendations for a new system that could better meet global Internet community needs for domain name registration data while offering greater privacy, accuracy, and accountability (EWG Project).

Purpose of RFI

The purpose of this RFI is purely informational – that is, to inform the development of policies and procedures that may follow both of these initiatives. As a result, potential Respondents responding to any future RFP for either the RAA Project or the EWG Project will not be bound by the estimates, prices, or other information provided in response to this RFI.

RFI Attributes

  • RFI Availability Date: 7 February 2014
  • The Requirements and Instructions are more fully described in the RFI [PDF, 395 KB]
  • RFI Close Date: 7 March 2014, 23:59 UTC
  • RFI Language: English only
  • Responses should be submitted via email to rfi-response@icann.org

ICANN greatly appreciates any insights on this topic from those commercial providers interested in sharing information about their services.

Background on the RAA Project

Registrars who are accredited under the 2013 RAA are currently required to perform limited validation of registration contact data. The agreement envisions that registrars will also perform cross-field validation of address data (e.g., the house number exists on the street, which exists in the city and province, and the postal code is correct). This cross-field validation requirement becomes effective 6 months after ICANN and a working group of registrar volunteers have agreed that cross-field validation is technically and commercially feasible.

ICANN has convened the registrar working group that is exploring address validation service options. The RFI published today intended to help inform that working group’s work.

Background on the EWG Project

In December 2012, ICANN announced the creation of an Expert Working Group (EWG) on next-generation gTLD Registration Directory Services, as a first step in fulfilling the ICANN Board’s directive to help redefine the purpose and provision of gTLD registration data. The EWG’s findings are expected to serve as a foundation to help the GNSO create a new global policy for the provision of gTLD registration data.

A significant milestone was reached on 24 June 2013 with the publication of the Expert Working Group on gTLD Directory Services (EWG)’s Initial Report and FAQs, opening a consultation period with the ICANN community. The Initial Report [PDF, 1.70 MB] enumerated the users, purposes, data elements, recommended principles and features, and proposed model to guide the development of a next generation Registration Directory Service (RDS) to replace WHOIS.

Prior to the ICANN Meeting in Buenos Aires, the EWG published its Status Update Report [PDF, 2.26 MB] to highlight the EWG’s thinking on these and many other key issues. It also provides a great deal more detail on the analysis that lay behind the Initial Report [PDF, 1.70 MB].

The EWG is currently in its research and information gathering phase. This RFI is one of several research efforts that the EWG is currently undertaking to ensure that its final recommendations are supported by facts and informed by current practices.

The EWG expects to complete its recommendations in 2014, informed by Community feedback and in-depth analysis of selected areas, including the responses to this RFI. The EWG plans to reconvene in March 2014 to derive fact-based recommendations after carefully examining the results of its research, and expects to deliver its final report to the ICANN Board by June 2014.

Questions

If questions arise about the RFI regarding the EWG Project, please contact Margie Milam, or Mike Zupke regarding the RAA Project. Any such inquiries should be sent to PP-EWG-Survey@icann.org.

This ICANN announcement was sourced from:
www.icann.org/en/news/announcements/announcement-07feb14-en.htm

ICANN: Notice of Preliminary Determination To Grant Registrar Data Retention Waiver Request

ICANN logoICANN has made a preliminary determination that it is prepared to grant a data retention waiver request submitted by Registrar OVH SAS under the 2013 Registrar Accreditation Agreement (the “2013 RAA“). Section 2 of the Data Retention Specification (the “Specification”) of 2013 RAA provides that prior to granting any exemption under the Specification, ICANN will post its determination on the ICANN website for a period of thirty (30) calendar days.

Pursuant to Section 2 of the Specification, OVH SAS submitted to ICANN a Registrar Data Retention Waiver Request (“Waiver Request”) on the basis of OVH SAS’s contention that compliance with the data collection and/or retention requirements of the Specification violates applicable law.

The Waiver Request was accompanied by a legal opinion from French counsel asserting that compliance with the data collection and/or retention requirements of the Specification violates Article 6-5 de la loi du 6 janvier 1978 ainsi que la Directive 95/46/CE (Article 6-5 of the law of January 6th 1978, as the European directive 95/46/CE).

The Waiver Request concerns Articles 1.1.1 through 1.1.8 of the Specification and seeks to reduce from two years to one year the period for which these specified data elements must be retained after the Registrar’s sponsorship of the Registration ends.

Following review of the materials submitted by OVH SAS, ICANN has determined on a preliminary basis that it is prepared to grant the data retention waiver request. ICANN is posting this preliminary determination for a period of thirty (30) days to seek feedback and input from the community on the proposed data retention waiver. After the thirty (30) day period following this posting has expired, ICANN will consider all feedback and input received before making a final determination on whether to grant the Waiver Request.

The scope of the proposed waiver would be to permit OVH SAS to maintain the information specified in Articles 1.1.1 through 1.1.8 of the Specification for the duration of its sponsorship of the Registration and for a period of one (1) additional year thereafter rather than two (2) additional years thereafter. In all other respects the terms of the Specification would remain AS-IS.

The specific change to the Specification would be that, for the duration of the Waiver, the retention requirement of Paragraph 1.1 of the Data Retention Specification be changed from “two additional years” to “one additional year.”

If ICANN does make a final determination to grant the Waiver Request sought by OVH SAS, the provisions of Section 3 of the Specification would apply to similar waivers requested by other registrars located in the same jurisdiction. Section 3 of the Specification provides as follows:

If (i) ICANN has previously waived compliance with the requirements of any requirement of this Data Retention Specification in response to a Waiver Request from a registrar that is located in the same jurisdiction as Registrar and (ii) Registrar is subject to the same applicable law that gave rise to ICANN‘s agreement to grant such wavier, Registrar may request that ICANN to grant a similar waiver, which request shall be approved by ICANN, unless ICANN provides Registrar with a reasonable justification for not approving such request, in which case Registrar may thereafter make an Wavier Request pursuant to Section 2 of this Data Retention Specification.

A public comment period will remain open until 5:00 p.m. PDT/California, 27 February 2014. Public comments will be available for consideration by ICANN staff and the ICANN Board.

OVH SAS’ Waiver Request and supporting documents are available here: OVH SAS Data Retention Request and Supporting Materials

Comments can be posted to: comments-ovh-sas-27jan14@icann.org

Comments can be viewed at: forum.icann.org/lists/comments-ovh-sas-27jan14

This ICANN announcement was sourced from:
www.icann.org/en/news/announcements/announcement-27jan14-en.htm

Second Level Registrations And Other Changes Coming To .UK In 2014

Nominet logoThere are major changes to the .uk ccTLD are coming in 2014 including registrations at the second level, enhanced security, a revised Registrar Agreement and a proposed Data Quality policy is open for comment, the .uk registry, Nominet announced yesterday (20 November).

The change that will catch the public’s eye is registrations at the second level which will mean registrants will be able to register theirname.uk as well as the existing theirname.co.uk.

“In an industry that is seeing an unprecedented level of change with the upcoming introduction of over a thousand new top level domains, we’re hard at work to ensure innovation in .uk keeps UK web users and businesses ahead of the curve,” said Nominet CEO Lesley Cowley.

“At the same time, we’re holding ourselves to a higher standard – expanding the choices available to our customers, upping the bar for security, data quality and the way we engage with our registrars to ensure everyone registering, managing or visiting a website with a domain ending in .uk can be proud to be part of a strong, trusted community.”

The change to add second level registrations will occur in the northern summer of 2014. Over ten million existing .uk customers will be offered the shorter equivalent of their current address, with five years to decide whether they want to use it in addition to, or instead of the domain they already have.

To deal with disputes in the small number of cases where different registrants may have registered, for example, the .co.uk and .org.uk domain, the shorter domain will be offered to the .co.uk registrant.

The wholesale price, that is the price charged to registrars, for the new domains will be £3.50 per year for single year registrations and £2.50 per year for multi-year registrations. This is the same price as a current co.uk domain, ensuring the cost of a domain name will remain a very small proportion (around 1.5% for a small business) of the cost of being online.

All Nominet’s existing domains (.co.uk, .org.uk, .net.uk, .me.uk, .plc.uk, .ltd.uk and .sch.uk) will continue to run as normal.

Nominet is planning a major programme of communication and outreach with its customers to ensure people are aware of the changes, and intends to announce a definitive launch date by February 2014.

Another ccTLD, .nz, has also announced plans to introduce registrations at the second level in 2014.

.UK Security

In other changes, Nominet announced that in Q1 2014 they will be launching new tools to help registrars further enhance the security of their domain portfolios, including a domain-locking tool to protect high value domains from social-engineering attacks.

From Q2 2014, registrars will be offered the opportunity to adopt additional security controls when accessing Nominet’s registry systems, to give the domains they manage a stronger second line of defence against hacking.

Nominet is also exploring ways to work alongside others in the internet community to help businesses address the increasing challenge of cyber-security and take advantage of opportunities to build a trusted online presence.

Work is underway to develop a tool aimed at helping anybody who has a .uk web presence identify when security-related issues are adversely affecting their domain, with a view to encouraging the take up of additional website security features.

A separate initiative is exploring how Nominet can work alongside others in the internet community to offer practical help to small businesses concerned about cyber-security.

Nominet has also developed a data visualisation and analysis tool to assess the behaviour of the domain name system. This has already helped prevent a global exploit of the domain name system and Nominet hopes to deploy this technology in a number of ways to help keep the internet safe.

Registrar Agreement

Another change is to the Registrar Agreement. A final draft of Nominet’s new Registrar Agreement has been published with amendments based on consultation feedback. These include a new, clear policy regarding Nominet’s commitment and expectations around data quality, as well as a decision not to introduce tag fees at this time.

Registrars and other interested stakeholders are invited to submit comments by 20 December 2013. The final version of the agreement is expected to be agreed in early 2014 and registrars will then be given 30 days notice before it comes into force.

Data Quality

As part of their ongoing commitment to raising the standard of information held for .uk registrations, Nominet’s proposed data quality policy has been published [pdf]. It sets out data quality requirements and commitments for Nominet and its registrars moving forward.

Anyone interested in this issue is invited to give their feedback on the proposed policy by 20 December 2013. Feedback will be published (where permission has been granted) in the New Year.