Leo,
You previously wrote, that "If there is no cooperation, this can go down until the deregistration." I don't see how a threat of deregistration fits alongside a statement that dealing with bogus data is outside the scope of your proposal.
I understand this concern and partly share it, which is why I am personally extremely sceptical about the part that would make an abuse-c mandatory (by syntax or business logic) without a clear timeline and migration path. Previous changes to syntax and logic have been accompanied by some timeout and default action, that would have moved obsolete attributes into remarks field or likewise. Now, this may or may not make sense for the proposal at hand, but I do not intend and also do not recommend to create massive amounts of compliance violations by introducing abuse-c and then waiting for "nothing" to happen. This would have to be covered by an NCC impact analysis (due in a potential next step in the PDP) and, IMHO, belongs under "arguments opposing this proposal" in the current version.
I searched the RIPE NCC's web site and could not find any description of systemic processes for evaluating and improving the quality of registration data.
I am not aware of such a process, either. There is, however, process in place that is triggered on a case by case basis. -Peter (member of, but not speaking for the TF)