ICANN ICANN Email List Archives


<<< Chronological Index >>>    <<< Thread Index >>>

Key-Systems comments on Whois Accuracy Program Spec Review

  • To: comments-whois-accuracy-14may15-en@xxxxxxxxx, RrSG EXCOM <rrsg-excom@xxxxxxxxxxxxxxxxxxxx>
  • Subject: Key-Systems comments on Whois Accuracy Program Spec Review
  • From: Volker Greimann <vgreimann@xxxxxxxxxxxxxxx>
  • Date: Thu, 02 Jul 2015 13:42:38 +0200

Dear ICANN team,

Key-Systems is pleased to be able to submit its comments regarding the Review.

Key-Systems is deeply dismayed by the chilling effects and negative consequences this spec has had over the brief time it has been in effect, leading to over a million domain names suspended world-wide and a significant increase of consumer support required. Understanding however that a wholesale removal of the specification will be unlikely, even though highly desirable, we comment as follows:

The Implementation details and interpretation of the Specification by ICANN compliance have uncovered a number of issues that need urgent clarification or rewriting to appropriately cover the original intent of the parties when drafting this specification.

Re: ICANN staff comments:
Section 1:
1) A clarification of the terms validation and verification would be helpful, especially in an international context. 2) A clarification for manual verification may not be helpful, as it might reduce the ability of the registrar to employ various means to achieve the desired result. If a clarification is provided, it needs to be as broad as possible as not to exclude potential means of verification a registrar may conceivably employ.
3) This clarification would be helpful.

Section 2:
1) At the same time, the section should be more clear that it only applies to material changes. Fixing typos, etc should not trigger revalidation or re-verification.

Section 5:
1) We reject any proposal that would expand verification requirements to any fields that only require validation under the current spec. While the registrar may have the option to verify newly provided data in the listed occurrences, making it a requirement is unreasonable and uneconomical at least, and may be potentially impossible. Required verification should remain limited to email address and/or telephone number as envisioned in the drafting of the specification. There is no basis for an expansion of verification requirements to other fields.

Re: RrSG comments:

Section 1:
1) We agree with this proposal as a suspension upon transfer is indeed potentially harmful to existing businesses of the registrant. We also point out that under the transfer policy, the FoA requirement already provides for a verification of the email address as the registrant must respond to a trigger sent by the gaining registrar.
2) We agree with this proposal.
3) We agree that there should be no limit on how a registrar performs the validation or verification. If he for example wants to walk past the address or look it up on Google Maps, that should be permissable just the same. 4) We agree with this proposal. Thus far, no commercially reasonable service or solution for a cross-field validation has been suggested. Key-Systems is of the opinion that no such service that meets the requirement of a free, worldwide service for cross-field validation with acceptable error rates exists at this time.
5) We agree with this proposal.
6) We agree with this proposal.
7) We agree with this proposal.
8) We agree with this proposal. This clarification is needed.

Section 2:
1) We agree with this proposal. Simple corrections or minor changes should not trigger validation and verification. This causes significant user confusion and encourages the opposite of what the specification is supposed to achieve as the registrant will now have to jump through additional hoops just to correct an incorrect whois entry.
2) We strongly agree with this proposal.

Section 4:
1) We wholeheartedly support this proposal. Unsubstantiated complaints should not be given and time of day. They belong in the bin, not in a verification routine. Any complaint must be sufficiently substantiated to even be considered. 2) This section has in its currnt form caused sufficient heartache and confusion that this proposal does not go far enough. A re-verification of an email address does not even make sense when the corrected part was the telephone number, the street address or the name. We therefore throw our full support behind the proposal to remove the re-verification requirement for email-addresses for any other case than that where it was the email address that was incorrect. We further propose that language be added to clarify what an incorrect email address means, as currently it is read to include temporary delivery failures or failures to successfully send e-mails to an IDN-email address as well, for example if the email postbox is full. This should not be considered an invalid email address, but rather a non-functional, but correct email address and not trigger the re-verification requirement.
3) We agree to this proposal.

Section 5:
1) We agree with this proposal, see our comments to Section 4, Nr 1.

Section 6:
1) We fully support the proposal to regularly review the specification, as some effects may not be visible at the time of the first anniversary and any updates or modifications resulting from the initial or any subsequent reviews should also be subject to further reviews.

Section 7:
We fully support both proposed amendments.


Should you have any further questions, please do not hesitate to contact us.

Best regards,

Volker A. Greimann
- legal department -

Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann@xxxxxxxxxxxxxxx

Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com

Follow us on Twitter or join our fan community on Facebook and stay updated:

CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534

Member of the KEYDRIVE GROUP

This e-mail and its attachments is intended only for the person to whom it is 
addressed. Furthermore it is not permitted to publish any content of this 
email. You must not use, disclose, copy, print or rely on this e-mail. If an 
addressing or transmission error has misdirected this e-mail, kindly notify the 
author by replying to this e-mail or contacting us by telephone.

<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy