Hello, in (not only) ORGANISATION object we had abuse-mailbox field available already, even it was optional.
From database point of view creates current implementation inefficient overhead (both technical and administrative) - there's requirement of new ROLE object containing abuse-mailbox insteand simple filling of abuse-mailbox in ORGANISATION object. And only! role - even existing PERSON has abuse-mailbox optional, too...
Even if we have abuse-mailbox filled in ORGANISATION object (and also having IRT object with referencing mnt-irt containing similar information), new abuse-c ROLE is _required_ in ORGANISATION object. This require modification of _every_ ORGANISATION object, even if there was reference of abuse-mailbox in other way already. Mentioned mnt-irt was usable in INET(6)NUM object without any problems. So your argumentation about abuse-c in INET(6)NUM doesn't make sense. Why we cannot have here abuse-c role and/or abuse-mailbox fields? Why abuse-mailbox in current PERSON fields (used in admin-c/tech-c) isn't sufficient? IRT object is - in the fact - also abuse contact point. We used it to reference direct abuse contact to end-user of particular IP space (because direct abuse-mailbox I cannot use in INET(6)NUM). New abuse-c implements almost similar thing... In general, I think it's wrong, when several working groups should modify database scheme by their own policies. Not every person is watching all RIPE mailing lists. DB-WG should be arbiter here in all cases, and not only RIPE-NCC - i don't thing RIPE NCC / ANTI-ABUSE-WG considered all existing possibilities (specially IRT, abuse-mailbox in other objects...). Current implementation is still inconsistent - somewhere I can use abuse-c, somewhere abuse-mailbox directly, somewhere mnt-irt... but there're objects, where some of fileds mentioned above I cannot use. The goal is simple - publish abuse contact and I support this at all. But from database point of view - there're several ways - and all should be valid (not only abuse-c ROLE). Even adding abuse-mailbox and abuse-c to INET(6)NUM. This goal can be reached by multiple ways. Requirement of _new_ field, where existed other options already is wrong and unsystematic. About documentitation you mentioned (this is job of RIPE NCC) - it should be updated - not (only) archived. You used a lot of links for your argumentation - this should be in _single_ place, in documentation (not only in mailing list archives, not only in blogs etc). In general - informations are on too many points and you described that clearly (ANTI-ABUSE-WG, DB-WG, RIPE-LABS etc). One of RIPE-NCC role should be some kind of coordination between all working groups. I wrote this long email with one goal in the mind - things should be kept simple and stupid... With regards, Daniel On 07/01/2013 06:10 PM, Denis Walker wrote:
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... 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.ht...
In a follow up RIPE Labs article https://labs.ripe.net/Members/denis/creating-and-finding-abuse-contacts-in-t... 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.ht...
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