Richard Hartmann wrote:
On Tue, Nov 9, 2010 at 14:06, Florian Weimer <fweimer@bfk.de> wrote:
I'm not concerned with data accuracy. It's with availability of the data itself, given current policies set and implemented by RIPE NCC.
I agree that the current IRT model does not scale. I, wrongly, assumed that irts could just be created without fuss as the webupdate interface pretends you can simply add them without any manual verificiation of RIPE.
A staged system (created, verified, etc) might make sense for IRT. This would allow the RIPE to verify what they want to verify, yet allow the RIRs to update quickly.
Alternatively, the requirements for IRTs could be losened.
Please remember that the IRT object was not designed for general abuse handling. It was created for Incident Response Teams (hence the name) who handle the bigger Internet network and security problems. This is why it has "encryption:" and "signature:" attributes and is referenced by a maintainer attribute that requires authorisation to add a reference to an IRT object. We have already weakened its main purpose by making the above attributes optional. For Incident Response Teams these should be mandatory attributes. Now they are required attributes, but as we cannot distinguish between the two different roles this object now serves we cannot enforce this requirement. If we loosen the requirements any further for the IRT object it will no longer serve its original purpose. Regards Denis Walker Business Analyst RIPE NCC Database Group
Finally, an unverified abuse-c could function in parallel to a verified IRT. This obviously introduces other problems.
All that being said, I still feel that a mandatory, unified, non-rate-limited abuse contact Is A Good Thing.
Richard