Hi,
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.
If the current system was so obvious to everyone: - why do so many data maintainers put abuse contact details in "remarks:"? - why do so many users send complaints to email addresses found in "notify:" and "changed:" attributes? - why does anyone use "abuse-mailbox:", which has always been optional, when "admin-c:" has always been available? - The "admin-c:" has never been defined as an abuse contact. It is not reasonable to assume that everyone who linked an email address to that attribute wants to receive abuse complaints on that address, even if some do.
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.
Just to clarify what the implementation is really doing, because it seems that some things have been mixed up a little bit. - Add 2 new attributes, "role-type:" and "abuse-c:" - Add NO new objects - Optionally remove the IRT object as it fits well as a role type - Optionally replace "mnt-irt:" attribute with an "irt-c:" - Remove "abuse-mailbox:" from MNTNER, ORGANISATION, PERSON objects - Keep "abuse-mailbox:" and "e-mail:" in ROLE object
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.
A new system often looks more complicated than something you are familiar with. Imho it makes things easier to understand and much easier to maintain.
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.
What if the administrative contact is not the place to report abuse to. Just because other companies are different then yours? And admin-c, as I understood it is not the (System) Administration. What would we do in this situation? Where would we store phone number and other information about an abuse department. Because in other companies there are abuse departments wanting to publish these information.
In case the contact chose to not have/want/need a special abuse address, there are still the canonical addresses for this contact.
Which are usually all spam filtered, because these addresses are in many cases personal addresses. Beside that since these are personal addresses they are underlying query restrictions.
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...
If that would have been the intend I would have worded the Proposal exactly in this way ;-) But since I have not and the whole working group agreed on this wording and not another it should be clear that this was not the intention.
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.
Nobody said, that we are removing the e-mail attribute and I can not follow the reasons above, because I do not completely understand the reasons above, because they are referencing just wrong information. That confusion starts already with the fact that the abuse-mailbox attribute shall be mandatory. That is in general just wrong. The abuse-c is mandatory and the object that will be referenced by the abuse-c has to have an abuse-mailbox attribute. If you use your usual object and add an abuse-mailbox or if you create a complete new object for an abuse department and add an abuse-mailbox there is completely open. In other words, if you have 10 different objects and you have to publish an abuse-c there is only need to add an abuse-mailbox attribute to 1 object. Hope this makes things more clear. Thanks, Tobias -- abusix