[RDS-WHOIS2-RT] Data Accuracy subgroup draft report
Volker Greimann
vgreimann at key-systems.net
Mon May 28 10:29:16 UTC 2018
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 2^nd
> 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.
--
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
Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems
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
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
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:
www.facebook.com/KeySystems
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
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/6ed47a58/attachment-0001.html>
More information about the RDS-WHOIS2-RT
mailing list