[anti-abuse-wg] WHOIS (AS204224)

HI Ronald

On 05/11/2015 23:44, Ronald F. Guilmette wrote:
> In message <563A6462.7080708 at yahoo.co.uk>,
> denis <ripedenis at yahoo.co.uk> wrote:
>
>> You{r} talk about privacy and this whole thread is about making lots of
>> personal data public and how many over engineered processes can be put
>> in place to the detriment of all the good folk to trip up a few of the
>> bad folk.
>
> Excuse me, but I think that perhaps you have been reading some
> entirely different thread on some entirely different mailing list
> someplace.  Either that or else you're employing scare tactics to
> try to derail what was a simple discussion about validating contact
> data which is already in the public data base.

First of all I apologise if I have mixed up some of your views, some of 
Sacha's views and some of my own views. If I have I did so with good 
intentions. I was not trying to derail anything, but I disagree that 
this is a simple discussion.

>
> I started this thread, and have actively participated throughout.
> I, for one, *never* proposed or even vaguely suggested "making lots
> of personal data public" to use your words.  That is a grotesque
> mischaracterization of the discussion up till now, I think.  It's
> totally out of left field and has nothing whatever to do with the
> (informal) proposal on the table.
>
> Personal data _is_ already and currently present in the publically-
> accessible RIPE data base.  You may personally object to that fact.
> If so, then fine.  State your objection and make a proposal for
> change.  But please do not put words in other people's mouths.
>
> Speaking only for myself, I made no suggestion whatsoever to increase
> the amount of personal information present in the data base.
> Mr. Luck, for his part, has clearly and vigorously expressed the
> view that the amount of such information in the data base (and/or
> in the publically accessible part thereof) should be decresed to zero.
> But the decision to do, or not do that is totally orthogonal to
> the separate decision of whether or not to check the data for
> validity.  The data can be checked and left public.  The data can
> remain both unchecked and public.  The data can be checked and can
> be hidden behind a paywall.  Or the data can remain unchecked and
> can disappear behind a paywall, just as, it appears, Mr. Luck
> would prefer.
>
> I object also to your use of the loaded phrase "over engineered processes".
> This is clearly intended to make it sound as if some exceptionally
> complicated Rube Goldberg Apollo Moon-shot system is being discussed.
> That is not the case.  Millions of businesses world-wide allow end
> users to create accounts on their corporate web sites, and the vast
> majority of those then COMFIRM and VALIDATE those account creations
> by sending the person who is alleged to have created the account a
> magic cookie (often embedded within a URL) and asking them to return
> that in some fashion.  Many other businesses employ an analogous
> process only with telephones.  Still others perform an analogous
> process with snail-mail.  If these all constitute "over engineered
> processes" then I'm sure that news will come as shock to all those
> millions of businesses who have spent time and money to implement
> and deploy theses systems.

On this point I believe you are wrong. "allow end users to create 
accounts on their corporate web sites". This is not how the RIPE 
Database works. The accountability for these 'accounts' is distributed. 
The RIPE NCC has no relationship with many of the personal data sets 
created in this database. So first of all any validation process must 
also be distributed. So are you saying one process must be agreed by 
policy and this one process must be employed by all data creators at all 
levels within this structure? How do you plan to validate the validation 
process? The RIPE NCC members add a lot of personal data into this 
database. The contract the members sign requires them to ensure data 
added to the database is accurate. But claims have been made on this 
mailing list that not all members are equally trusted. Are you 
suggesting the RIPE NCC should re-check what was entrusted to the 
members to do? If not do you trust all the data entered by all members 
as they are required to check it? If a policy sets down some validation 
process and all members are expected to implement it, do you trust all 
members to use that process?

In the end most members do enter valid data that they have checked by 
some means in good faith. So any process you define by policy will put 
workload onto mostly honest businesses doing the right thing already. 
This is what I had in mind when I used the phrase 'over engineered'.


>
>> Seriously, with a review of the data model we can end up with:...
>
> So let me see if I understand this...
>
> So on the one hand, performing even just some simple process to
> try to validate data fields that are already in the public data
> base is an "over engineered" solution, but YOU want to totally
> re-engineer the entire data base from the ground up.  Is that
> about the size of it?  Did I miss anything?

Yes you did miss something. I never suggested we through out the baby 
with the bathwater. I proposed a discussion on reviewing the data model. 
That is not suggesting we through out everything we have now. It may 
lead to re-arranging data, storing it more efficiently, or maybe storing 
different data, or only allowing some of the data to be seen by groups 
of people who need it.

As I said above, validating data in a system with a distributed 
accountability is not going to be simple.

>
> I personally have no reason to be either for or against the idea
> of entirely throwing out the existing data base and redesigning
> and re-implementing it from scratch.  If that proposal seems
> worthwhile to the majority, then by all means it should be done.
> What I _do_ object to is having a pie-in-the-sky redesign-from-scratch
> proposal thrown into the mix while discussing what started out as
> an exceptionally modest, simple, and above all *incremental*
> and purely *procedural* change... a change that would have no effect
> at all on either the content or the structure or the permissions
> associated with the data base as it currently exists.

I think you have over complicated my point while over simplifying yours. 
My main point was that there are many issues with personal data, 
including validation, and maybe we should take a step back and look at 
them all.

cheers
denis

>
>
> Regards,
> rfg
>
>
> P.S.  I do understand that many people have ideas... some of them
> excellent, some of them less so... about how the structure, content,
> or public-accessibility of the data base should be changed, going
> forward.  I do not begrudge anyone who advances such ideas.  I only
> request, humbly, that discussion of these other ideas not be
> confusingly intertwined with discussion of the (admittedly still
> informal)  _procedural_ proposal that I've put forward.  That only
> serves to confuse matters all around, befuddling everyone.
>