[db-wg] Re: abuse-c: proposal

Hi Peter,



> > My requirements as an operator[2] are clearly not met, I get loads of
> > abuse complaints to my notify and changed addresses every week, which I
> > have to forward to either the abuse dept or /dev/null.
>
> So, the problem is mainly a marketing/education problem. No
> matter what change
> to objects or presentation will be agreed upon, nothing short of limiting
> access to the database would stop the uneducatable or "let's hit them all"
> type uncooperative tool writer. The education or usability
> problem can IMHO
> best be achieved with a dedicated interface for "abuse" purposes, be it a
> web interface or a dedicated whois server. No new objects are needed.
>
> -Peter

I disagree.

If ALL IP lookups in the whois gave an abuse email address at the beginning
of a page which was more likely to be answered than mails to notify/changed
addresses then users would surely start to use this instead.

The problem is that currently we do not have an easy way to enter such an
address, I understand that we have the IRT object but almost no LIRs use it
probably because its a bit too complex, it contains many more features than
is necessary to solve our abuse-address problem - which mean it doesn't
solve anything.

If we could get consensus to solve this problem we should try to find an
easy solution likely to be implemented by the majority of the LIRs. My
suggestion has been to include the abuse adddress in the maintainer object,
it could default to the upd-to address, meaning all inetnum objects would
instantly reference an abuse address.

Secondly inetnum objects could include an optional abuse address attribute
in case some LIRs prefer to differentiate. If an abuse address is present in
the inetnum objects this has to be displayed at the top of the page in a
whois query, if its not present then it should default to the address in the
maintainer object.

I don't see any purpose in the IRT object when we haven't even making sure
an abuse address is available for all inetnum objects (which is probably the
only thing all non-LIR-users use the Ripe DB for), but I don't see any
problem in keeping the IRT object if some LIRs find it useful.




Med venlig hilsen/Best regards

Christian Rasmussen
Hosting manager, jay.net a/s

Smedeland 32, 2600 Glostrup, Denmark

Email: noc at jay.net
Personal email: chr at corp.jay.net
Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301

Produkter / Products:
http://hosting.jay.net