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

SUN Lili L.SUN at interpol.int
Mon May 28 03:41:50 UTC 2018


Hi Volker,

I inserted my responses in lines below in red, for the information and further comments of the whole RT.

Thanks,
Lili

From: RDS-WHOIS2-RT [mailto:rds-whois2-rt-bounces at icann.org] On Behalf Of Volker Greimann
Sent: Friday, 25 May, 2018 7:53 PM
To: rds-whois2-rt at icann.org
Subject: Re: [RDS-WHOIS2-RT] Data Accuracy subgroup draft report


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.

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?

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”.

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.

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.

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.

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”.

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.

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”.

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.

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.

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.

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.






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/rds-whois2-rt/attachments/20180528/99ddc8f6/attachment-0001.html>


More information about the RDS-WHOIS2-RT mailing list