[RDS-WHOIS2-RT] Data Accuracy subgroup draft report

Wed May 30 10:14:52 UTC 2018

Hi Volker,

I believe the divergence between us roots in the understanding or interpretation of accuracy. I checked once again about the definition of “accuracy” in the 2010 NORC study (used Whois requirements of 2009 RAA as benchmarks),  quoted below for information.

Under Registrar Accreditation Agreement Section 3.3.1.6, an accurate name and postal address of the registered name holder means there is reasonable evidence that the registrant data consists of the correct name and a valid postal mailing address for the current registered name holder. Adapting this for the study, there were three criteria to be met for any WHOIS record to be considered accurate:

1.       Was the address of the registrant a valid mailing address?

2.       Was the registrant named associated in some way with the given address?

3.       When contacted, would the named registrant acknowledge that they were indeed the registrant of the domain name, and confirm all details given as correct and current?

As such, the core of accurate Whois data is contactable while with association with the registrant. The NORC study defined “Substantial failure” as “Undeliverable address and/or unlinkable name, however registrant located. Unable to interview registrant to obtain confirmation; Deliverable address, but unable to link or even locate the registrant, removing any chance of interview”. Again, if the information in the record has no association with registrant, it will be deemed as “Substantial failure”.

The Whois ARS project has checked syntax and operability accuracy described in the SAC058 Report so far. The operability accuracy checks the functionality of the information in a record (e.g. Does the email go through? Does the phone ring? Will the mail be delivered?). In this context, whether the information in a record has association with registered name holder has not been checked (postponed to Phrase 3 – Syntax + Operability + Identity accuracy). Thus, Phrase 1 plus Phrase 2 are contactable test only, Phrase 3 has not started yet, there is no reason to take Whois ARS project “over- or underperforms the recommendations”. Again, I insisted that even a Whois record could perfectly pass syntax and operability check, while has no association with the registered name holder, which will deem as inaccurate.

I do agree some registrars would be fully compliance with RAA, but as exposed during Whois ARS project, some registrars don’t, the evidence is that the inaccuracy could be remedied  after Compliance informing, or the relating domain names were suspended or cancelled. If the issue could be remedied at this stage, why the validation and verification couldn’t be down upon registration? You may argue that “Who should pay for that?”, but this is a responsibility registrar should take according to RAA.

I also want to remind you that unfortunately, except registrars who may have internal accounting /ticket system to keep tracking registrant not only on Whois data, but also billing information, the public Whois data is the only information that legitimate users or generic public could access about registered name holders. If the Whois data is outdated or even falsified, it could be a mislead for the information users.

Last but not least, I understand your standpoint as a representative of registrar, but as a review team member, please keep neutral. What have been reviewed in this subgroup falls in the Action Plan provided by ICANN and contractual obligations of RAA. We are not in the position to challenge decisions have been made.

Thanks,
Lili

From: Volker Greimann [mailto:vgreimann at key-systems.net]
Sent: Monday, 28 May, 2018 6:29 PM
To: SUN Lili <L.SUN at interpol.int>
Cc: rds-whois2-rt at icann.org
Subject: Re: [RDS-WHOIS2-RT] Data Accuracy subgroup draft report

Hi Lili,

responses inline.

Regarding Section 3.2, I am a bit puzzled why no reference at all is made to a significant qualifier included in Rec 6. Rec 6 only refers to reducing the occurrence of the accuracy groups of Substantial Failure and Full Failure (of contactibility of the contact). In other words, if there is a partial inaccuracy, this would not even be covered by the recommendation if sufficient contactibility is maintained by the remaining contact points. WHOIS ARS does not make such a differentiation either, and instead goes beyond the recommendation as it merely looks for any error in the data regardless of whether the remaining data provides for sufficient contactibility. The data from the ARS would have to be analyzed in more significant detail before making the determination of whether the recommendation was implemented. I also am not convinced that the observations under 3.2 are fit to match the recommendation, and some are baseless speculation:
The NORC study defined “Substantial failure” as “Undeliverable address and/or unlinkable name, however registrant located. Unable to interview registrant to obtain confirmation; Deliverable address, but unable to link or even locate the registrant, removing any chance of interview”; defined the “Full failure” as “Failed on all criteria - undeliverable address and unlinkable, missing, or patently false name, unable to locate to interview”.
In this context, my view is that both Syntax check and Operability check are not necessarily linkable to the registrant. A Whois record could perfectly pass Syntax and Operability check while has not a single linkable information of the registrant. I don’t think “sufficient contactibility” is the objective of Rec #6, the essence of Rec #6 is how much relevant the Whois data to the registrant. The WHOIS ARS leave the identity check to the last stage, which means the relevance has not been checked yet.

1) This may very well be the case, but eneral improvement of the whois data is not what the recommendation is about. The recommendation is about achieving a certain level of accuracy, not total accuracy as the ARS is designed for.
This observation is an overall assessment of the impact of WHOIS ARS.
We should also comment on how the ARS implementet the recommendations and where it over- or underperforms the recommendations. Both are important when looking at how ICANN implemented the recommendations.

2) We should not speculate on causes for reasons of why the numbers are what they are. Accordingly, the entire second paragraph should be removed.

Disagree. The fact was already there, the review means assessing the implementation, identifying problems/issues, and putting out new recommendations, if the RT doesn’t dig into the reasons, how can the RT recommend?
I have no objections against fact-based reviews of reasons, however we should not enter into the realm of speculation. I therefore object to the inclusion of any conclusions that are not based on research and facts but only on pure speculation. Otherwise we could also blame anything on the phases of the moon or the ascendancy of Jupiter in Virgo.

3) Again, the inaccurate rate is of no importance in the contect of the recommendation. The only rate of concern would be that of inaccuracies that would be considered as Substantial and Full Failure of contactibility of the contact. Therefore this observation has no relevance to the recommendation as it stands.

See above. The objective of Rec #6 is to reduce the inaccuracy in a measurable way, and Syntax + Operability accuracy doesn’t mean the criteria of not falling in Substantial failure have been met. As such, I used the term “confirmed”.
I disagree with the interpretation of that objective. The recommendation specifically determines the inaccuracy levels it is concerned with. Inaccuracies in general or 100% accuracy were not the objective of that recommendation. The language here is clear.

4) Instead of seldom, I would use the term "very rarely, and only in the first cycle" to correctly reflect the numbers. Four cases of breach notices out of 2,688 tickets is statistically irrelevant.

The statistics were quoted from WHOIS ARS Contractual Compliance Metrics<https://whois.icann.org/en/whoisars-contractual-compliance-metrics> as a fact.
Correct. I only object to the word "seldom". We should be specific when interpreting the statistic. In this case, the breach notices only occurred in the first cycle.

With regard to section 3.5, I fully disregard with the phrasing of the statement in section 4 that refers to "... if the WDRP were fully enforced...". We have no reason to believe that at this time this policy is not fully enforced and followed by registrars merely because of a report ICANN issued in 2004, especially as the followig section points out that we do not have reliable data from the compliance audit program. We must look at the situation today and if we have no data on that, we cannot make such a statement. I therefore suggest to strike the entire last paragraph of section 4. If anything, we should ask for compliance to provide better and more detailed data.
The enforcement of WDRP was reflected in the following paragraph, and only sampled registrars were audited and no detailed information on how the registrars remedy deficiency on WDRP compliance is provided in the audit report. Regarding the statement of “Thus, there is good reason for this subgroup to believe that if the WDRP were fully enforced at annual basis, there would be a quite positive impact on Whois accuracy.”, that’s the assessment of the impact of WDRP policy you mentioned below, I’ll leave it for open discussion of the whole RT.
Again, we have no indication that the WDRP requirement is not fully enforced. Your statement indicates it is not, which is a false statement.

Further, the recommendation focusses on the impact of these messages, not on the observance of the policy by contracted parties, so the fifth paragraph focussing on registrar compliance misses that point entirely and should be removed. I agree with the assessment that rec 9 has not been implemented though.

I don’t understand this comment well. The statement above is the impact of WDRP policy. As a proactive measure to improve Whois accuracy, the assessment of WDRP enforcement is necessary in my opinion.
I disagree. Even if the policy were not properly enforced and only a small number of registrars followed it (which we have no indication for), we could still analyse how the policy impacts those registrants that receiver it, which is what the recommendation was about.

4.0-4.5 This section should again loses focus of the actual content of the recommendations to improving contactibility, not overall accuracy. We should therefore rephrase this section accordingly. Instead of "accuracy" and "reliability" we should use instead the terminology of sufficient contactibility, substantial and full failure.

See Above. Again, I don’t agree “the actual content of the recommendations to improving contactibility, not overall accuracy”.
The recommendation is clearly phrased. If it wanted to recommend full accuracy, it would have not used the substantial failure and full failure. If you interpret it otherwise, that is not covered by the language they intentfully used, but rather implies your own agenda.

4.2. What is the basis for this belief? As the ARS program took great lengths to create a significant sample size, its results regarding accuracy as a percentage should have some statistical relevance regarding the overall inaccuracy. Also, inaccuracies should be graded by the standards laid down in the recommendations. Insignificant inaccuracies that do not affect contactibility were still reported by the ARS program and included in the statistics, but play no role in the evaluation of the implementation of the recommendations. For example, many ARS compliance reports we received were for formatting errors where the data in the WHOIS, while accurate, did not match the format prescribed by the RAA, was entered in the wrong field, etc. Such inaccuracies do not normally affect contactibility.

The rationale was depicted in the 2 paragraphs already.
I disagree with the rationale.

4.3 I disagree with the section headline. The contractual compliance report to the contrary demonstrates proper enforcement of these obligations as they demonstrate the enforcement actions taken upon discovery of a deficiency. I also would argue for the removal of the section regarding Avalanche, since it is anecdotal at best and has no implication on compliance as the obligations are phrased in a way to allow multiple venues and methods of verification.

To validate the format of Whois data and then verify Whois data are contractual obligations of registrar, it should be done upon registration, not to be dealt with after being discovered by complaints from community and/or WHOIS ARS. And according to contractual compliance report, the top issue with regards to registrar compliance on WHOIS inaccuracy is “registrars failing to verify or validate Whois information as required by 2013 RAA”.
Your answer misses my point. This paragraph suggests whois obligations are not properly enforced based on the fact that there are inaccuraties. This is a fallacy, as the contractual obligations do not prevent all inaccuracies. An address can be perfectly formated and therefore validatable and the email address verifyable and the whois record may still be inaccurate for any number of reasons. The registrar can be fully compliant with his obligations under  the 2013, but those do not guarantee accurate whois data and therefore cause whois inaccuracy complaints.

I agree that the example of Avalanche currently has no relevance to compliance, it’s only a demonstration that registrar is in the best position and is also capable to verify Whois data.
OK

4.4. seems to be missing a word in the headline.
Also, as the the privacy proxy service take the role of the registrant in the public whois, on the accuracy of its own contact data should be of relevance for whois accuracy. Any issues with inaccuracies of the underlying data do not factor into the recommandations as issue for this subgroup. Instead any discussions of underlying data accuracies should be restricted to the privacy proxy subgroup.

I agree that “underlying data accuracies should be restricted to the privacy proxy subgroup”, as it’s invisible to this subgroup. What has been outlined here is the facts of Whois check when it comes to P/P service.

4.5. As inaccuracy of whois is not at issue, this entire section would need reworking. I also do not agree with its conclusion that the measures are not sufficient to fulfill the targets of the recommendations.

I totally disagree that “inaccuracy of whois is not at issue”, that was the reason why Rec #5-9 were to reduce the Whois inaccuracy.
Only to a specific point, not inaccuracy in general. Reading more into the recommendation abuses them for purposes not intended.

I also reject the assumption of the perception of non-compliance by registrars with their obligations. From my own experience, most inaccuracy reports received are not preventable by the measures required by the RAA. A record may be fully validatable and verifyable, yet still be incorrect. For example, an address may be perfectly formatted in accordance with the requirements, thus passing every required validation, yet still be incorrect due to the street not existing or being the address of someone else. I therefore strongly suggest removing the last paragraph of section 1 of 4.5.

Your example perfectly indicate that validation is not enough, a following verification is needed to make sure the Whois information belongs to the registrant.
Needed for what? Who should pay for that? As even cross-field verification is commercially unfeasible, verification of identity is impossible to achieve from a commercially reasonable perspective.

Best,
Volker

Am 25.05.2018 um 12:40 schrieb SUN Lili:
Dear all,

Sorry for the late submission.

Please refer to attached the revised version of the Data Accuracy subgroup draft report, which incorporated the discussion of 2nd F2F meeting and answers to the follow up questions on Data accuracy and Compliance from ICANN.

As to the proposed recommendations, I’ll reflect in Compliance subgroup draft report.

Thanks,
Lili
***************************************************************************************************
This message, and any attachment contained, are confidential and subject of legal privilege. It may be used solely for the designated police/justice purpose and by the individual or entity to whom it is addressed. The information is not to be disseminated to another agency or third party without the author’s consent, and must not be retained longer than is necessary for the fulfilment of the purpose for which the information is to be used. All practicable steps shall be taken by the recipients to ensure that information is protected against unauthorised access or processing. INTERPOL reserves the right to enquire about the use of the information provided.
If you are not the intended recipient, be advised that you have received this message in error. In such a case, you should not print it, copy it, make any use of it or disclose it, but please notify us immediately and delete the message from any computer.
*************************************************************************************************

_______________________________________________

RDS-WHOIS2-RT mailing list

RDS-WHOIS2-RT at icann.org<mailto:RDS-WHOIS2-RT at icann.org>

https://mm.icann.org/mailman/listinfo/rds-whois2-rt

--

Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.

Mit freundlichen Grüßen,

Volker A. Greimann

- Rechtsabteilung -

Key-Systems GmbH

Im Oberen Werk 1

66386 St. Ingbert

Tel.: +49 (0) 6894 - 9396 901

Fax.: +49 (0) 6894 - 9396 851

Email: vgreimann at key-systems.net<mailto:vgreimann at key-systems.net>

Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net>

www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com>

Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:

www.facebook.com/KeySystems<http://www.facebook.com/KeySystems>

www.twitter.com/key_systems<http://www.twitter.com/key_systems>

Geschäftsführer: Alexander Siffrin

Handelsregister Nr.: HR B 18835 - Saarbruecken

Umsatzsteuer ID.: DE211006534

Member of the KEYDRIVE GROUP

www.keydrive.lu<http://www.keydrive.lu>

Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.

--------------------------------------------

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 at key-systems.net<mailto:vgreimann at key-systems.net>

Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net>

www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com>

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

www.facebook.com/KeySystems<http://www.facebook.com/KeySystems>

www.twitter.com/key_systems<http://www.twitter.com/key_systems>

CEO: Alexander Siffrin

Registration No.: HR B 18835 - Saarbruecken

V.A.T. ID.: DE211006534

Member of the KEYDRIVE GROUP

www.keydrive.lu<http://www.keydrive.lu>

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.

--