On 05 May 2015, at 15:59,
denis walker <ripedenis@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:
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