[db-wg] IRT object postal address (denis walker)
- Previous message (by thread): [db-wg] IRT object postal address
- Next message (by thread): [db-wg] IRT object postal address (denis walker)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
William Weber
william at inbox.li
Fri Jul 22 13:50:49 CEST 2022
As cybercriminal i wholeheartedly support the idea of removing all personal data from the RIPE DB. That would make my life so much easier. -- William On Fri, Jul 22, 2022 at 12:00 PM <db-wg-request at ripe.net> wrote: > Send db-wg mailing list submissions to > db-wg at ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.ripe.net/mailman/listinfo/db-wg > or, via email, send a message with subject or body 'help' to > db-wg-request at ripe.net > > You can reach the person managing the list at > db-wg-owner at ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of db-wg digest..." > > > Today's Topics: > > 1. Re: IRT object postal address (denis walker) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 21 Jul 2022 15:41:58 +0200 > From: denis walker <ripedenis at gmail.com> > To: "Ronald F. Guilmette" <rfg at tristatelogic.com> > Cc: Database WG <db-wg at ripe.net> > Subject: Re: [db-wg] IRT object postal address > Message-ID: > < > CAKvLzuE+RoNgGXL8TU3r4E5dOtOd3uweB9UzFJhgnOmpBruU+g at mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Ronald > > (For those who don't read long emails...) The bottom line is that this > proposal recommends to remove postal addresses of contacts, not > publish the 'full' postal address of natural persons holding > resources, replace personal data with business data and generally > bring the contents of the RIPE Database into line with the defined > purposes. > > --- > Now to answer Ronald's points... > > You have your own (hidden) agenda Ronald, which is fine. But don't > expect everyone to fall into line behind you. Most people know your > tactics. Repeat the same nonsense and conspiratorial theories over and > over and over again until people believe they must be true. You lock > onto a phrase or even a word and create an entire fear mongering story > around it. Then keep asking the same irrelevant questions and > demanding answers. This is not how to have a professional discussion, > it is a Trump/Johnson style campaign. > > Let's kill off some of your fear stories. I am NOT against > accountability, NOT helping cybercriminals, NOT proposing anonymity, > NOT obfuscating half the database, NOT proposing secrecy and NOT > avoiding transparency. > > As for GDPR, the only person obsessed with it is you Ronald. It is not > even mentioned in the proposed policy text. You use it to confuse all > discussions on the content of the database. GDPR is only one of the > factors concerning the content of the RIPE Database. There are defined > purposes for the database. As the RIPE Database Task Force pointed > out, we should minimise the amount of data needed to fulfil those > defined purposes. That is the overriding principle governing what > should go into the database and what remains in the database. > > Most people did accept that in order to resolve internet operational > issues (one of the main purposes of the database) no one is going to > visit or post a letter to a contact in the RIPE Database. Therefore > contacts don't need postal addresses. Whilst you may feel there is a > need for a postal address for a contact for an IRT object, as Nick > said, the opinions of CSIRT teams are more relevant. > > You have said yourself many times that the database is full of > garbage. When you demand irrelevant data and force people to enter > information they prefer not to provide which is not even covered by > the database purposes, you increase the chances of some people > entering false or misleading information. The only 'crusade' I am on > is to bring the contents of the RIPE Database into line with the > minimum information required to fulfil the defined purposes of the > database and any legal requirements. We can have a healthy discussion > on interpretations of that minimum information, but we should not be > arguing over the principle. Forcing people (with mandatory attributes) > to enter 'interesting' but not relevant information leads to a corrupt > and diluted database that is less useful to anyone. Even optional > attributes that are not relevant, dilute the important information. > > You can wish for any information you like to be in the RIPE Database > Ronald, but if it is not essential for the defined purposes, it is not > going to be there. Feel free to propose your own policies to change > the purposes of the database and store certified photos of all > contacts and their families if you believe that is necessary for your > use of the database...or set up your own database. > > cheers > denis > proposal author > > On Thu, 21 Jul 2022 at 06:01, Ronald F. Guilmette via db-wg > <db-wg at ripe.net> wrote: > > > > In message < > CAKw1M3MEHHC63+BfS7P365F0Cw6hcGuOKKq0ZaTS+evtdiZDoQ at mail.gmail.com> > > =?UTF-8?Q?Cynthia_Revstr=C3=B6m?= <me at cynthia.re> wrote: > > > > >> *) Why is the hiding of information even a priority? > > > > > >Hiding information is good from a privacy standpoint so you have to > > >weigh the benefit of having the data public against the privacy > > >implications of publishing it. (and consider any potential legal > > >issues/requirements) > > > > Transparency is good from an accountability standpoint. And in my > opinion, > > we have far far too little accountability on the Internet. Practically > > every day now one can find stories about "hackers" and "cybercriminals" > > and everyone just shrugs and goes back to work as if this is the way that > > thing have to be, or that they are supposed to be. > > > > My position is simple: If youy want to be anonymous, then get yourself a > > pseudonym account on Twitter, or Facebook, or YouTube, or whatever, and > > then blast away. Or alternatively, get yourself a domain name with all > > of the WHOIS data redacted and then arrange wweb site hosting for that, > > either on one IP of one hosting company, or several. But somewhere up > > the chain there needs to be accountability, always. It is *not* a God- > > given right to have an IP address block or an ASN. It is a privilege. > > And that special privilege should be reserved for those who are willing > > to be held accountable for what goes on upon their networks. > > > > You and Denis are trying to _remove_ accountability from the equation, > and > > I remain steadfast in asserting that this will only benefit criminals. > > > > >> *) Are these deliberate obfsucation steps still being justified on > the > > >> basis of GDPR, or do you now accept as fact that GDPR is irrelevant in > > >> the context of the RIPE data base, and that it does not currently > compel > > >> RIPE to make any changes to the public WHOIS data base whatsoever? > > > > > >Denis has already mentioned in an email regarding 2022-01 that he will > > >not address any more GDPR issues until there has been a legal review > > >as many of us are not lawyers. > > > > I'm sure that I saw someone post here quite recently that he had checked > with > > RIPE legal already, and had already been assured that RIPE is _not_ > facing > > any current or imminent legal jeopardy with the status quo as it now > exists, > > either in relation to GDPR or in relation to any other applicable law or > > regulation. If you need me to do so, I will find that posting in the > archives > > and I'll copy it here. > > > > >While I can't speak for Denis, you have not convinced me that GDPR is > > >somehow irrelevant > > > > I don't see how or why it should be incumbant upon either me or anyone > else > > to persuade either you or Denis that no change needs to be made. You > and he > > are putting forward and supporting this proposal for a _change_ in the > > current status quo. It is thus necessary for you folks to make a > persuasive > > case that a change _is_ needed, rather than for me or anyone else to > make a > > case that it isn't. > > > > >> *) If the goal is to hide information, then why not just take the > entire > > >> RIPE WHOIS data base offline and hide the whole thing behind some > sort of > > >> permission-wall that can only be pierced with a legal warrant? > > >> > > >> (That last question is, of course, the essential point, since that > endpoint > > >> seems rather clearly to be the direction in which this is all headed.) > > > > > >This question is not really an "essential point" in my opinion as > > >there is a big difference between hiding postal addresses and hiding > > >abuse email addresses and route(6) objects. > > > > You are doing just what Denis has done so far in relation to this whole > > thing... You are evading the question. If transparency is "bad" and > > secrecy is "good" then why not take that general principal to its final > > and logical conclusion? Why not just take the whole WHOIS data base > > offline entirely? > > > > It's a simple question. I'd like to see either you or Denis answer it, > > rather than evade it. > > > > > > Regards, > > rfg > > > > -- > > > > To unsubscribe from this mailing list, get a password reminder, or > change your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/db-wg > > > > ------------------------------ > > Subject: Digest Footer > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/db-wg > > > ------------------------------ > > End of db-wg Digest, Vol 131, Issue 14 > ************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.ripe.net/ripe/mail/archives/db-wg/attachments/20220722/0666c9cd/attachment.html>
- Previous message (by thread): [db-wg] IRT object postal address
- Next message (by thread): [db-wg] IRT object postal address (denis walker)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]