[anti-abuse-wg] abuse-c cleanup

Dear colleagues,

> On 05 May 2015, at 15:59, denis walker <ripedenis at yahoo.co.uk> wrote:
> 
> When the original implementation plan was put forward for "abuse-c:", the time line (if I remember correctly) was:
> -allowing 6 months to deploy to all members allocations
> -then 12 months to deploy to all independent resources
> -then do a cleanup

I believe you are referring to this:
https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011-06 <https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011-06>

> Can the RIPE NCC confirm that all resources now have an "abuse-c:"?


No, there are still organisations without abuse-c associated with resources.

1 = Some LIRs are still missing abuse-c

Once the abuse-c has been set up for an organisation it cannot be removed, although it can be modified. However, "abuse-c:" still needs to be set for some LIRs created after phase-1 was completed. This is due to the fact that until recently new LIRs needed to create their own maintainer, abuse-c role object manually after membership activation. So new cases of LIRs that do not have an abuse-c set up were added every day.

We updated the member activation process recently and now a maintainer and abuse-c role are created as part of the activation process.

So, going forward we can now contact the remaining LIRs to set the abuse-c, and be sure that no new cases are created. We have not done this yet, because we were focusing on implementing the phase 1 and 2 of deprecating changed first.

2 = Not all organisations have an abuse-c

The RIPE NCC only has a policy mandate to enforce abuse-c for organisations associated with resources allocated or assigned through the RIPE NCC. I.e. organisations holding legacy resources or assignments made by LIRs are not covered.


> The idea of "abuse-c:" was to create one single place/way of documenting abuse contact details. So far all that has been achieved is to add a fourth way to document it. All the old ways ("abuse-mailbox:" in 5 object types, IRT and remarks) are still littered throughout the database.


A schema change like this would need to be discussed in the database working group, and can only be done in case "abuse-c:" can be made mandatory for all organisations - and this would also have to be discussed there.

From a technical point of view this change is not necessarily difficult to implement, provided that missing abuse-c roles could be created using either the existing abuse-mailbox or email attribute on organisations - presumably the addresses people would turn to today in the absence of an explicit abuse-c. So, in a way this change should not have a big semantic impact. Consistency would help to reduce complexity in documentation and business rules. It would also make it easier when assigning resources to new non-LIR organisations - now we need to check whether abuse-c has been set, because it's not mandatory and we often find that this makes dealing with requests longer.

But that said, the above is only a partial picture of this, and this should in our view be discussed in the database working group. We can implement after consensus is called.



Kind regards,

Tim Bruijnzeels

Assistant Manager Software Engineering
RIPE NCC




-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/anti-abuse-wg/attachments/20150506/ac16b1c9/attachment.html>