[gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
theo geurts
gtheo at xs4all.nl
Sun Oct 9 20:33:56 UTC 2016
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 at netearth.net
> <mailto:chris at 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 at ripe.net
> <mailto:rleaning at ripe.net>>
> *To: *"Michele Neylon" <michele at blacknight.com
> <mailto:michele at blacknight.com>>
> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg at icann.org
> <mailto:gnso-rds-pdp-wg at 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 at blacknight.com <mailto:michele at 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
>
> http://www.blacknight.host/
>
> http://blacknight.blog/
>
> http://ceo.hosting/
>
> 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 at icann.org
> <mailto:gnso-rds-pdp-wg-bounces at icann.org>> on behalf of
> Richard Leaning <rleaning at ripe.net <mailto:rleaning at ripe.net>>
> *Date: *Friday 7 October 2016 at 19:20
> *To: *Greg Shatan <gregshatanipc at gmail.com
> <mailto:gregshatanipc at gmail.com>>
> *Cc: *gnso-rds-pdp-wg <gnso-rds-pdp-wg at icann.org
> <mailto:gnso-rds-pdp-wg at 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 at icann.org <mailto:gnso-rds-pdp-wg at 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 at icann.org <mailto:gnso-rds-pdp-wg at 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 at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20161009/cb08e587/attachment.html>
More information about the gnso-rds-pdp-wg
mailing list