[gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose

Sun Oct 9 20:12:33 UTC 2016

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> 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>
> *To: *"Michele Neylon" <michele at blacknight.com>
> *Cc: *"gnso-rds-pdp-wg" <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> 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
>
> Direct Dial: +353 (0)59 9183090
>
> -------------------------------
>
> 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> on behalf of Richard Leaning <
> rleaning at ripe.net>
> *Date: *Friday 7 October 2016 at 19:20
> *To: *Greg Shatan <gregshatanipc at gmail.com>
> *Cc: *gnso-rds-pdp-wg <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
> 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/01c6d35e/attachment.html>