[anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database)

Hi!

[...]
> but business rules will require it to be
[...]

I didn't find any "business rules" document at RIPE.

>From the thread I understand that the intention is to make the abuse-c an actually mandatory attribute, at the same time kind of removing the e-mail attribute and making the abuse-mailbox by definition a bulk target.

Now I have to think about a crowd of real persons with a ripe handle, referenced as admin-c for their objects. They would have to add an abuse-c (or otherwise somebody will try to take their resources away from them!?), i.e. they will usually just add their e-mail there once more (if they don't have an abuse-mailbox attribute yet - probably because they don't need it because the value in the e-mail is perfectly what they want to communicate for this purpose as well) - while this email was made a bulk target by definition (in which case they probably even preferred to remove the abuse-mailbox if they had one in favour of their e-mail attribute - which would just be made impossible by the proposal), and at the same time their e-mail would be made unusable.
One hell of a vision you got there, I'd say... ;)

[though not explicitly stated, the following seems to be meant as justification of the proposal]
> Currently within the RIPE NCC service region, it is not clear whether to use the "abuse-mailbox:" attribute, the "remark:" attribute or an irt object. And since the "abuse-mailbox:" attribute can be added to various role objects, it is not clear in which of these role objects it should be preferred.

When I read that I assumed it had to mean that it is proposed to drop "abuse-mailbox", "remark" and the irt object.
Later in the thread I had to find out that it isn't.
In case the mentioned attributes/objects are really to be dropped in favour of the single new attribute, I might see a benefit in simplifying things. I don't say yet that this justifies a policy change, but at least there would be some sort of point in it...
The implementation document kind of summarizes this aspect quite drastically, too. It describes the goal of 'going back to basics', 'avoiding complexity' in quite some length, and concludes in adding several attributes, objects, and quite some mainly undefined policy stuff while removing nothing at all.

In short I can't see any benefit from this proposal. It doesn't simplify things, it makes things (including finding abuse contact information) more complicated and for a huge part of the community it introduces severe problems. We're better off as it is now. The "Arguments supporting the proposal" are in my eyes simply unsustainable.
Another cue regarding the possible aim I found was: "The outcome is, to have an abuse-c in place. That is all." Well, that's not true as discussed above, there are major problematic implications, and on the other side, simply to have another attribute doesn't seem like a valid justification to me. I mean, it's not "to have an abuse-mailbox", which would bear some sort of sense in itself in my eyes - while of course this has been done already.
Actually I do not even see the motivation for an 'abuse industry' to lobby this at all!?

But I don't think that this kind of policy should be following particulate interest but should be universal anyway. Like this:
- a resource has an administrative contact (complaints - whether abuse or not - are administrative issues)
- a contact can have an explicit address for abuse reports. In case the contact chose to not have/want/need a special abuse address, there are still the canonical addresses for this contact.
This is what we have, and while there might be problems somewhere that should or could be addressed, I don't see the problem the 2011-6 proposal fixes (or actually even formally addresses)!?
If you want to force every resource holder to have and publish an email that is explicitly meant to be bulk-spammed, you should propose exactly this (i.e. making an abuse-mailbox mandatory for the admin-c and announcing it as proper use to bulk spam these addresses). As a victim of this I'd ofc still be very much against this. And once again, I'm really wondering what the businesscase might be to motivate such a situation...

Making the abuse-c attribute actually mandatory as described, imho is a very very bad idea for the reason given above. Effectively removing the e-mail attribute imho is too, though probably sligthly less important than the previous issue.

Well, at least time to update the "Arguments opposing" paragraph, I'd say... (dropping the proposal wouldn't be wrong either, I'd say)

Regards,

	Chris