I agree there Greg, you need to look at the context of the data, I like the examples. What is missing is a database so you can cross check the data. And there lies the problem, there is no such database or tool available. You would think if there is a commercial solution out there we would have already started using that right? Such a tool would be used all over I guess. But we don't, because it does not exist. Sure Fedex works nicely, and they usually deliver most of the stuff you order, but there are countries they heavily need to rely on asking directions, yes real old school. Accuracy is important, the examples here are countless, but accuracy should not be confused with trying to achieve the impossible. Accuracy should be a realistic goal. I think most of us are on the same page here. Best Theo On 9-10-2016 22:12, Greg Shatan wrote:
Going back to my earlier post, not all contact data is equally fault-tolerant. Some can be resilient, some can be brittle. Data needs to be looked at in context as well. Looking just at the dataset of contact data we see in WHOIS, some mistakes or missing data will result in non-contactability, while other mistakes or missing data can be worked around with other data in the dataset.
For example, take my old phone number -- 1-212-995-2768. In one sense, phone numbers are not at all fault tolerant -- if you don't have all the numbers right, you will not get through. In another sense, some parts of a phone number are fault tolerant, while others are not. For instance, if you have a missing country code (1) but you have the area code or my address, you can easily solve the missing country code problem. If you're missing the area code, that's a bigger problem. Assuming it's a landline and the area code is an accurate reflection of geography, you could like at the address; however, my physical address has 3 possible area codes, so that's not so simple. If it were a mobile number, the missing area code could be fatal, since my physical address could be anywhere in the world. If any of the last 7 numbers are missing or inaccurate, that's fatal in terms of "mechanical" solutions coming from the rest of the dataset. Finally, note that I said this was my _old_ phone number -- even if all the numbers are right you won't be able to reach me, because it's an old number and calling it only tells you the number is no longer in service.
Physical addresses can also be fault tolerant, to an extent, without going beyond the dataset. First, some information isn't entirely necessary. You can leave out my zip code and I'll still get the mail, perhaps a day or two late if it gets bumped out to manual sorting, because the remaining information is sufficient. Similarly, you can leave my apartment number off, and I'll probably still get it, but it's no longer a certainty (I leave in a 140-unit building and our regular mailman probably know which apartment I'm in, but a substitute might not.). Leave out my street name and I won't get it, even if all the other information is correct, because the remaining information is insufficient. Similarly, because I live in New York City, you could leave out the state, but if I lived in Middletown, NY, you can't, because there's a Middletown in the majority of US states.
Analysis of fault tolerance of particular data or using other data within the dataset is appropriate in my view. However, I don't think it's appropriate in our context to look at external solutions to determine whether data is "functionally accurate," whether it's Googling it, figuring it out or hiring a private detective (or being a detective). This takes us out of the realm of self-sufficient solutions, and in most cases, takes us out of the realm of automated solutions, bringing in the use of human resources on a case-by-case basis. It also takes us largely out of the realm of rules-based solutions. These fuzzy factors make it impossible to characterize any data type as functionally accurate, because it depends on unknowns (as far as the data at hand goes) in order to resolve an issue, if it can be resolved at all. Even if contact can be can be resolved in spite of the missing datum, the time, effort and cost involved in doing so are orders of magnitude higher than a solution using other data in the dataset.
Finally, I may be too cavalier regarding the ability to resolve missing data using other data in the dataset. It can depend on the user and the purpose, and whether contact using fully accurate data is done in a mechanized fashion for that user and purpose. It also depends on the workflows and the capability to develop methods to apply the remaining data to solve the problem posed by missing data. I've assumed something of a reasonable best case scenario in that regard, and skewed my thoughts to uses I'm more familiar with; as a result, my working assumptions regarding functional accuracy and the use of other data in the dataset (or proceeding without certain data) may be too optimistic.
Greg
On Sun, Oct 9, 2016 at 3:05 PM, Chris Pelling <chris@netearth.net <mailto:chris@netearth.net>> wrote:
HI Dick,
I think you will find that all registrars will already strive for accuracy as best they can, certainly when it comes to email address and/or phone depending on what they use to validate.
In your point regarding reaching you by phone or email, I sort of agree, but disagree, if someone truly (and this is in respect to you as you stated yourself) wants to get hold of you, a very small bit of investigation with Google would give Ripe's number and a call to Ripe would in one way shapr or another get ahold of you. -- Edge case I know, but I was directly responding to that point.
I suppose at some point in the future I am sure the same discussions our group is having will trickle down the IANA side of things in relation to RiR's moving over to RDS and having the same data issues we are currently discussing. :)
Kind regards,
Chris
------------------------------------------------------------------------ *From: *"Richard Leaning" <rleaning@ripe.net <mailto:rleaning@ripe.net>> *To: *"Michele Neylon" <michele@blacknight.com <mailto:michele@blacknight.com>> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> *Sent: *Sunday, 9 October, 2016 18:09:39
*Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Michele,
I don't disagree with you. There will always be scenarios where common sense prevails.
But if you want to phone me you will need the accurate number - not something that looks like my number.
If you want to respond to me about these comments, you will need the accurate email address not something that is sort of my email address.
All am saying is we should strive for accuracy knowing that we may not achieve it but at least let's try.
Cheers
Dick
Richard Leaning RIPE NCC External Relations (Sent by iPhone)
On 9 Oct 2016, at 13:41, Michele Neylon - Blacknight <michele@blacknight.com <mailto:michele@blacknight.com>> wrote:
Dick
Sorry, but that’s absolutely untrue. So I agree with Greg.
I have been getting postal mail for more than 30 years and over that period my name, my gender and my address have been listed inaccurately hundreds of times.
Yet the postal services in the various countries that I’ve lived in have been able to get the mail to me.
There is a very big difference between “functional” and “accurate”.
As others have pointed out, it’s often impossible to provide 100% accurate addresses on web forms etc., Try updating your ESTA for a visit to the US and you’ll find 9 times out of 10 that the address form doesn’t allow enough space for the hotel name and address. But if you provide the hotel name the authorities will know exactly where you are without the full address.
Our office address, for example, lists us as being in Carlow. If you actually looked at a map you’d see that we aren’t in Carlow, but in Laois.
Regards
Michele
--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
Intl. +353 (0) 59 9183072 <tel:%2B353%20%280%29%2059%20%C2%A09183072>
Direct Dial: +353 (0)59 9183090 <tel:%2B353%20%280%2959%209183090>
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,R93 X265,
Ireland Company No.: 370845
*From: *<gnso-rds-pdp-wg-bounces@icann.org <mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of Richard Leaning <rleaning@ripe.net <mailto:rleaning@ripe.net>> *Date: *Friday 7 October 2016 at 19:20 *To: *Greg Shatan <gregshatanipc@gmail.com <mailto:gregshatanipc@gmail.com>> *Cc: *gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org>> *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Thats Greg for articulating it so well.
all i was going to say was -
'You can’t contact someone if the contact information is inaccurate’
So i can’t see how you can split the two.
Richard Leaning
External Relations
RIPE NCC
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg