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

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





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 307 bytes
Desc: OpenPGP digital signature
URL: </ripe/mail/archives/anti-abuse-wg/attachments/20111208/67d5b1ce/attachment.sig>