[db-wg] NWI-7: abuse-c implementation plan

Dear working group,

We have a proposed timeline for the implementation. Let me quote the proposal sent out on 28 June here, and comment in-line:

> 1) Allow “abuse-c:” on INET(6)NUM and AUT-NUM objects
> 
> We will deploy a new version of whois where the “abuse-c:” attribute will be allowed to exist on INET(6)NUM and AUT-NUM objects. The syntax will be the same as for the ORGANISATION object:
> abuse-c:        [optional]   [single]     [inverse key]
> 
> The Abuse Finder logic will be updated to use the first "abuse-c:" found in this order of priority:
> -the local "abuse-c:" in the resource object
> -the "abuse-c:" in an ORGANISATION object referenced by the "org:" attribute in the resource object
> -search up the resource object hierarchy (less specific objects)
> --the "abuse-c:" in the less specific resource object
> --the "abuse-c:" in an ORGANISATION object referenced by the "org:" attribute in the less specific resource object
> 
> The search will stop when the top level resource object is reached.
> 
> In addition to this we plan to introduce a business rule that will disallow “abuse-mailbox:” to be modified, or (re-)added to any object, other than ROLE objects. This will enable us to do a phased clean-up of this data without invalidating objects.

We plan to have a whois release 1.90 for this (and the updated use of the ‘pn’ keyword mentioned under item #5 below) in the Release Candidate environment no later than Monday 2 October.

We plan to deploy this version to production on Monday 16 October.


> 2) Clean up of “abuse-mailbox:” on ORGANISATION objects
> 
> Three cases exist:
> 
> A) “abuse-mailbox:” is present and it is the same as the “abuse-mailbox:” in the also present “abuse-c:” reference (8919 cases)
> 
> In this case we propose to simply delete the “abuse-mailbox:” attribute and inform the holder. We will work on a clear text for this email, but the main message would be:
> "We removed “abuse-mailbox:” from your ORGANISATION object because this attribute is deprecated as the final step in the deployment of the "abuse-c:" attribute. However, we see that you were already using the preferred way to document abuse contact details for your organisation and you are referencing an “abuse-c:” ROLE object with the same email address in its its “abuse-mailbox:” attribute. No action is required.”
> 
> 
> B) “abuse-mailbox:” is present and it is different from the “abuse-mailbox:” in the also present “abuse-c:” reference (1848 cases)
> 
> Note that some of these cases have been caused by the fact that since the introduction of “abuse-c:” LIRs can no longer modify the value of the “abuse-mailbox:” attribute. The intent was that “abuse-mailbox:” would have been cleaned up earlier, but unfortunately that dit not happen. That being said “abuse-c:” has been kept up to date by the LIR, and out of the two is also the one that is being shown on the Abuse Finder.
> 
> Therefore we propose to delete the “abuse-mailbox:” attribute in these cases, and send a different notification to the holder with the following main message:
> 
> "We removed “abuse-mailbox:” with value $email from your ORGANISATION object because this attribute is deprecated as the final step in the deployment of the "abuse-c:" attribute. However, we see that you were already using the preferred way to document abuse contact details for your organisation and you are referencing an “abuse-c:” ROLE object with that uses $email_2 in its “abuse-mailbox:” attribute. If the latter is correct no action is required. However if you want to modify the email address in your “abuse-c:” ROLE object, you can do so here (link to webupdates).”
> 
> 
> C) “abuse-mailbox:” is present, and there is no “abuse-c:” reference (28312 cases)
> 
> We *could* create “abuse-c:” ROLE objects for these cases, using the same maintainers as the ORGANISATION object. However, the “abuse-mailbox:” attribute has not been shown in the Abuse Finder, and this change could lead to wrong or out-of-date addresses suddenly receiving abuse reports. Therefore we suggest that we delete the attribute instead, and send the following main message to the holder of the ORGANISATION object:
> 
> "We removed “abuse-mailbox:” with value $email from your ORGANISATION object because this attribute is deprecated as the final step in the deployment of the "abuse-c:" attribute. However, if you wish to add an email address for abuse reports you can do so by editing your object here (link to web updates for the ORGANISATION object)."
> 
> 

We plan to perform these clean-ups on Monday 30 October.

> 3) Clean up of “abuse-mailbox:” on PERSON (89k cases), MNTNER (2500 cases) and IRT (238 cases)
> 
> In these cases we propose to send a warning email to the holders of these objects with the following main message:
> 
> “The “abuse-mailbox:” is deprecated on these object and will be removed in 4 weeks, if you want to set up abuse contact information on your resource objects you can do so by having a default “abuse-c:” on your ORGANISATION referenced by your resource objects, or possibly overriding that default with a specific “abuse-c:” reference on applicable resource objects."
> 
> And then 4 weeks later we will preform the clean-up and refer back to this communication.

On further reflection we would prefer to alter the plan, and just a single clean-up of these objects on Monday 30 October as well. This way the clean-up process will be consistent across all object types. Furthermore, there is no action to be taken on these objects and “abuse-mailbox:” on these objects is ignored in the Abuse Finder. In short there does not seem to be a strong motivation for bothering the holders of these objects twice.


> 4) Clean up whois code
> 
> Now that “abuse-mailbox:” only appears where it should, we will be able to update the whois code itself so that “abuse-mailbox:” is no longer syntactically allowed on objects other than ROLE objects. This will allow us to remove the business rule added in phase 1 and simplify the whois code and maintenance. We will also update the RIPE Database Documentation to reflect this.

We plan to do this as part of a future whois 1.91 release, as yet unplanned. This clean-up will not change any publicly visible functionality.

> 
> 
> 5) Inverse queries
> 
> As requested we can change the behaviour of the “pn” short cut to also search for “abuse-c:” in inverse queries. I.e. one can use:
> whois -r -i pn uk41-ripe
> 
> Instead of:
> whois -r -i abuse-c,admin-c,tech-c,zone-c,author uk41-ripe

As mentioned above, we plan to include this in the whois 1.90 release.


Kind regards

Tim Bruijnzeels
Assistant Manager Software Engineering
RIPE NCC Database Group


> On 4 Aug 2017, at 14:39, William Sylvester via db-wg <db-wg at ripe.net> wrote:
> 
> 
> From: William Sylvester <william.sylvester at addrex.net>
> Subject: NWI-7: abuse-c implementation plan
> Date: 3 August 2017 at 21:12:06 GMT+2
> To: "db-wg at ripe.net" <db-wg at ripe.net>
> 
> 
> Working group members, 
> 
> Based on the responses we have received for NWI-7 : Abuse-c implementation, there is a clear consensus for the proposed implementation that has been presented by Tim from RIPE NCC as written for improving "abuse-c:". 
> 
> At this time, the DB-WG co-chairs would like to ask the RIPE NCC to proceed with this implementation.
> 
> Kind Regards, 
> 
> DB-WG Chairs
> 
> 
> 
> 
>