Hello Daniel, a lot of your concerns, questions and misunderstandings are clarified in official documents provided by RIPE NCC. I will go through your email and try to clarify some of these things, since I have been the proposer of this policy.
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...
The main idea of the proposal was to have "_ONE_" single place to publish abuse contact information and not several. That means: implementation of abuse-c takes several steps. One of them is a cleanup phase. This cleanup will try to clean up RIPE DB as much as possible. Within this step it will for example made sure that abuse-mailbox attribute will only be shown in abuse-c contacts and not in admin-c or tech-c objects in future. At the moment it is correct that it looks a bit messy. So please stay tuned a bit longer until clean up phases will start and show first results.
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...).
This is exactly what we didn't do. It was agreed by all involved WG that discussions will take place on AA-WG mailinglist. Updates about the policy proposal have been communicated on this list and in the sessions of all involved WG at every RIPE Meeting. In addition to that we discussed this in a task force and with RIPE NCC technical staff and let them come up with an implementation plan that also fits their plan of future development. So all important parties have been involved and agreed at the end to the implementation plan, which was of course publicly available.
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.
Right. This is a cause of a not already started clean-up phase, which can not happen before some other steps that are already in process.
The goal is simple - publish abuse contact and I support this at all.
Nearly right! The goal is to publish abuse contacts at "_ONE_" place that is always the same and does not let any space for discussions.
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.
This "all valid" ruleset lead to the "mess" we have in the database today. The mess you call inconsistency. ;-) We ended up having several different contact information about the same ip-address/range/space. Several as abuse-mailbox in addition with mnt-irt. This lead to confusion of people who didn't know where they should publish their data and confused the requester about where to look. abuse-c will fix all of these issues! Thanks, Tobias -- being 50% AA-WG Chair and 50% Policy Proposer in this email :-)