Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Please see the response from the ICANN Compliance Department.

"Quis custodiet ipsos custodes?" -Juvenal

...

Comments or questions here refer to the last (October 2012) Compliance Newsletter

  1. In reference to the "Volume of Complaints per Notification Cycle - Oct 2012" Bar chart, there appears to be a lack of context, for example the number of "closed" complaints exceeds the number of "received" complaints. There is no explanation of what these numbers really mean or how the related to each other. Can Compliance clarify the data?

  2. Under the "Responding to Whois Inaccuracy Complaints" section it is statedthat Registrar "Reasonable steps" include canceling the domain registration if the registered name holder (A) Provided inaccurate or unreliable information, (B) Failed to promptly update information, and/or (C) Failed to respond for over fifteen calendar days to inquiries. This appears to be in direct conflict with the Compliance advisory from 2003 which states in part that "Subsection 3.7.7.2 of the Registrar Accreditation Agreement does not require a registrar to cancel a registration in the event a customer fails to respond within 15 days", "the registrar is given discretion to act", "a registrar can appropriately conclude that much more than 15 days should be allowed before the registration is cancelled". Additionally, Compliance staff stated in the WHOIS Review Team Report that "there is no requirement in the RAA for registrars to ensure that WHOIS data is accurate." Compliance appears to overstepping its authority in the most recent newsletter and contradicting the standing policy without rescinding that policy. In the interests of transparency can Compliance cite the specific authority which allows ICANN to state that the "registrar should...cancel the domain registration" when this language does not exist in the contract?

  3. The "Enforcement Activity" Section of the Newsletter has no reference to the 14 September 2012 Breach of AB Connect Sarl, yet it has references to breaches issued before and after the AB Connect breach. Our specific question is: why is the AB Connect Sarl breach not listed in the October summary?

III. Review of Compliance Meeting in Toronto

In Toronto the Chair requested a follow up to a question asked in Prague concerning the "re-accreditation" of A-Technology Company after being de-accredited in a notice which states in part that "ICANN does not intend to renew the A Technology Company’s accreditation". In response Compliance stated that "The breach was cured 30th of June 2010." The problem with the answer is that A Technology's ability to cure a breach had already expired. Compliance also stated that:"The Registrar was not officially terminated", however the question concerned the de-accreditation or non-renewal. Regardless, it may be difficult for the casual onlooker to grasp these semantic differences, especially when the non-renewal notice states: "we look forward to amicably resolving any domain name transition issues that may arise from this termination." In general the timelines established in Compliance matters seem rather fluid. The questions are then, (1) at what point does a Registrar become officially de-accredited (whether through termination or non-renewal)? And (2) at what point are they required to completely submit a new application?


IV. Review of Compliance Recent Activities

  1. On 14 September 2012 AB Connect Sarl received a Breach/Non-Renewal notice from ICANN Compliance for failure to Escrow. The deadline to cure was 19 September 2012. As of 25 November 2012 there is no update on this breach and AB Connect Sarl is still listed as an active Registrar. Our specific question is: What is the status of this breach?

  2. On 19 November 2012 Bargin Register Inc. received a Breach notice from ICANN Compliance for a number of items with varying deadlines: Bargin must pay $3,845.44 by 30 November 2012 AND Bargin must supply communications, process relating to a UDRP by 12 December 2012. Our specific question is: The breach makes extensive reference to the Registrar's failure to comply with a UDRP process yet it does not hold the Registrar in breach of RAA 3.8 which states " Registrar shall comply with the Uniform Domain Name Dispute Resolution Policy", why?

...

  • Demonstrate the openness and transparency of ICANN's operations
  • Provide fair and equitable treatment to all business partners
  • Establish clear and easy-to-use channels for communication on compliance matters
  • Supplement staff knowledge and enable greater responsiveness to changes in the environment
  • Provide clear and regular communications to the community regarding contractual compliance activities, accomplishments and ongoing work
  • Identify areas for reform to be considered by the ICANN community


This recent Article in SecurityWeek notes a number of concerns without any response or quotes from ICANN staff