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@jay.net Personal email: chr@corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net