[anti-abuse-wg] Status of 2011-06

chrish at consol.net wrote:
> Hi!

Hi,

> On 01/12/2012 01:54 PM, Frank Gadegast wrote:
>> You will have no access restrictions for the abuse contact anymore
>> and the new abuse-c will be filled in a very short period because
>> it will be mandatory.
>
> The addresses entered into our ripe objects are not private data.

You are right, they are available for the public, but I meant the
definition of public and privat data according to law (well,
can only really speak for German law, but other countries
see that the same way).

So, they are public available, but they are no public data,
they are private data, specially the email address.
Its the same with e.g. domainowners, at least in Germany.
The data of the resource/domain owner is private and
has to be banned from automatic harvesting, thats why
you need a captcha code to reveal it at denic.de

Its the same with the admin-c in RIPEs resources.
They should be private, but they are still available
for automatic harvesting. This should be changed in a different
approach.

tech-c should stay public for routing issues.

And the new abuse-c has to be public too for automatic reporting.

Currently there is only some whois access restriction on some
parts of some objects, but thats wrong and should be changed later.
Some objects should be defined public including ALL their fields
and some should be restricted completely.

> They are public addresses for the purpose of ripe-stuff. Following
your idea abuse-cs would always be copies of the admin-c.

Not at all, the owner of a resource is something different than the 
abuse team or the routing team.

> A reasonable approach towards what seems to be your communicated aim would be:
> Drop all *-c in favour of a single contact

Nope.
"ripe-stuff" could be a lot of different things, and the plained three
contacts seem to be the best way to always address the right contact
for whatever purpose.

 > , which is meant as contact for ripe-stuff. This is of course public 
as it's meant that way. In case you actually wish for the possibility of 
multiple, specific contacts, the straightforward and all-compatible 
solution would be to add optional further specific contact data - that 
may be used by people who wish to direct mail to different specific 
addresses. Translated into the current state that would be: use an 
optional abuse-mailbox attribute (if this were mandatory, our objects 
would always just hold a copy of the e-mail attribute).
>
>> But maybe they will not find them attractiv at all, because they
>> know, that they will only reach professionals there, that can easily
>> seperated spam from good mail and that are trained not to click
>> every link in an email ;o)
>
> Yeah, that will certainly teach them.

We do not know until we have some numbers ...

>> But anyway: it will be possible to protect personal contacts much
>> better in the future, if the proposal gets through, because access
>
> Sorry, but it's just a stupid idea to put private data into public databases.

Surely right.
But what do you do, if the email address of the company owner needs
to be entered ?
Do you define and publish one, thats not read anyway ?
Do you enter one that does not exist ?

Or do you do it right and put the privat email address of the owner in ?

There should be a way to seperate public and private data and thats
whats the proposal plans. And if private data can be protected much
better, everybody could decide to put in, whatever he likes, even
the right thing ;o)


Kind regards, Frank


>
> Regards,
>
> 	Chris
--
MOTD: "have you enabled SSL on a website or mailbox today ?"
--
PHADE Software - PowerWeb                       http://www.powerweb.de
Inh. Dipl.-Inform. Frank Gadegast             mailto:frank at powerweb.de
Schinkelstrasse 17                                fon: +49 33200 52920
14558 Nuthetal OT Rehbruecke, Germany             fax: +49 33200 52921
======================================================================