From the proceedings we understood the requirement is to have a single location in the RIPE Database to store abuse contact details for any Internet resource and for this to be applied hierarchically to minimise management effort by the users and avoid unnecessary data duplication in
Dear Colleagues, Here is some background information to provide an insight into the reasoning behind the impact analysis and proposed implementation plan made by the RIPE NCC for policy proposal 2011-06. The RIPE NCC attended the meetings of the RIPE Abuse Contact Management Task Force (ACM TF) to understand the requirements and the underlining issues and advise on implementation details. We have also followed all the discussions on the mailing list. Several points have been raised and the RIPE NCC has been asked to clarify some of these points. the database. The reasoning behind the selection of a ROLE object for the task is partly based on our interaction with RIPE NCC member organisations. We understand that abuse handling in the real world is a role within an organisation. It therefore makes sense to map it directly to the ROLE object within the database. Also the original intention of the database design was to represent people by PERSON objects and to group people into roles using ROLE objects. Then only ROLE objects should be referenced in any other data objects. This avoids a situation which the RIPE NCC is regularly asked to help with when a person leaves a company and in some cases is directly referenced in tens of thousands of objects. This methodology is explained in the RIPE Database Update Reference Manual, but was never enforced in the database software. The proposal for decommissioning the IRT object was discussed briefly by the ACM TF. The RIPE NCC pointed out that with a general abuse handling ROLE defined, the IRT can be seen as a special case of the general ROLE. It would simplify the user interaction with RIPE database as well as the database design and management if the two were combined. The only reason that it was mentioned in the impact analysis was to point out the similarity of use cases and suggest a review if the policy passes. The RIPE NCC fully supports the view of the policy proposer to consider these as separate issues. The use of the phrase "plan to decommission IRT objects" in the impact analysis was not meant to imply the RIPE NCC would just go ahead and do it. Our intention was to raise the awareness with the community of the similarities of use and seek approval, or otherwise, to merge the IRT functionality with the more general "abuse-c:" implementation. The Abuse Finder tool available through the ripe.net website is a first iteration. We found it very difficult to define a proper scope for heuristics to identify the correct abuse contacts for any given resource with the current abuse contact documentation methods. A number of users have reported issues with this tool providing the wrong contacts. We held back from modifying the logic pending the outcome of the 2011-06 proposal. If the community agrees on a new method of storing abuse contacts the RIPE NCC will re-write the Abuse Finder tool to use the new contact details. As we have recently re-implemented the RIPE Database query service from scratch, we can also integrate the Abuse Finder directly into the query logic. It will then also be available through a web interface and by the RESTful API. During the transition from the current swamp of abuse contact data to the 2011-06 method (if approved) the RIPE NCC will aim to provide user tools to assist with updates, where possible. We hope this answers some of the questions raised regarding the implementation of the policy proposal 2011-06. Regards, Denis Walker Business Analyst RIPE NCC Database Group