This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[db-wg] abuse-c + org
- Next message (by thread): [db-wg] abuse-c + org
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Denis Walker
denis at ripe.net
Mon Jul 1 18:10:34 CEST 2013
[Apologies for duplicate emails.] Dear Gilles, These points were discussed on the Anti Abuse Working Group mailing lists quite extensively in June and December 2012. As you correctly pointed out policy ripe-563 says "This policy introduces a new contact attribute named "abuse-c:”, that can be included in inetnum, inet6num and aut-num objects." During the discussions last year it was asked if the RIPE NCC should 'interpret' policy. Our understanding is that this policy expresses the desire and goal of the RIPE community for a new feature in the RIPE Database. To achieve these goals this desire needs to be translated into, and incorporated in, an efficient, technical database design. In the RIPE Labs article https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011-06 we pointed out that there are about 3.7 million Internet resource objects in the RIPE Database. To add an "abuse-c:" attribute physically to each of these objects is unmanageable. Every users network is physically linked to their existing ORGANISATION object. Each user only needs to add one "abuse-c:" attribute in their ORGANISATION object and all their networks are covered. When any address is queried in the RIPE Database, the software will find the related "abuse-c:" reference and return this information as part of the query. By returning this information as a default with each query we have satisfied the policy requirement that the "abuse-c:" is "included in inetnum, inet6num and aut-num objects". It is not physically stored in each object in an unmanageable way, but logically associated with each object in an efficient and manageable way. This implementation was presented to and discussed by the community on the Anti Abuse Working Group mailing list last year and Brian declared that a consensus had been reached in his email on December 5, on behalf of the co-chairs of the DB and AA Working Groups: http://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2012-December/001993.html In a follow up RIPE Labs article https://labs.ripe.net/Members/denis/creating-and-finding-abuse-contacts-in-the-ripe-database the RIPE NCC explained how this implementation works in practise. You may recall that we discussed the details of how these references using the ORGANISATION object worked and how they can be fine tuned: http://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2012-December/001998.html The old RIPE Database reference manuals on the ripe.net web site still refer to the use of "abuse-mailbox:" attributes in other object types, but don't refer to "abuse-c:" at all. These attributes were never allowed to be added directly to the resource objects even in the legacy software. These old reference manuals are now out of date in many respects and should perhaps be clearly marked as archived documents. I hope this answers your specific questions. Regards Denis Walker Business Analyst RIPE NCC Database Team On 27/06/2013 10:06, Gilles Massen wrote: > Dear WG, and RIPE NCC staff, > > While trying to add an abuse-c to our resources, I was quite surprised > that you can only attach the abuse-c to an org object (while the policy > suggests otherwise and implementation notes are not very clear on the > limitation). > > So I'd like to ask why this restriction exists? What is wrong with > adding an abuse-c directly to an inet[6]num or aut-num? > > Best regards, > Gilles >
- Next message (by thread): [db-wg] abuse-c + org
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]