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

Colleagues
It is almost two weeks since Tim sent out a proposed implementation plan and timeline. Can we assume no comments mean acceptance? If anyone has any specific comments can we here them please.
Regardsdenisco-chair DB-WG

      From: Tim Bruijnzeels via db-wg <db-wg at ripe.net>
 To: William Sylvester <william.sylvester at addrex.net> 
Cc: DB-WG <db-wg at ripe.net>
 Sent: Wednesday, 28 June 2017, 13:57
 Subject: Re: [db-wg] NWI-7: abuse-c implementation request
   
Dear working group,

Here is the RIPE NCC's impact analysis and proposed implementation plan for the changes to “abuse-c:” that the working group seeks.

We expect that this will have a MEDIUM impact on the RIPE NCC. The RIPE Database Group Software team will have to implement changes, but because a clean-up of “abuse-mailbox:” is also in-scope of this proposal we also expect impact on our Customer Service department due to questions from users of the RIPE Database.

We propose an implementation using the following phases:

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.


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)."


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.


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.


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


Kind regards

Tim Bruijnzeels
Assistant Manager Software Engineering
RIPE NCC Database Group


> On 22 May 2017, at 20:56, 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 request
> Date: 22 May 2017 at 19:59:44 GMT+2
> To: DB-WG <db-wg at ripe.net>
> 
> 
> DB-WG Members,
>  
> Support was shown for the proposal NWI-7 and no objections were raised after this round of discussion. At this time, the chairs request that the RIPE NCC schedule implementation of NWI-7 as described.  
>  
> This request is to add the "abuse-c:" attribute directly to the INET(6)NUM and AUT-NUM resource objects. The db-wg therefore ask the RIPE NCC to prepare an impact analysis, followed by an implementation plan and timeline for this request and the other issues raised in the problem statement of NWI-7 as follows:
>  
> 1) Add the "abuse-c:" attribute to the INETNUM, INET6NUM and AUT-NUM objects
> 2) Adjust the query logic to take account of 'local' "abuse-c:" attributes in preference to those referenced in ORGANISATION objects
> 3) Allow both local and indirect references (via ORGANISATION objects) to "abuse-c:" attributes to operate hierarchically
> 4) Deprecate "abuse-mailbox:" attribute from PERSON, ORGANISATION, MNTNER and IRT objects.
> 5) Clean up data relating to the deprecated attributes.
> 6) Update the 'person' keyword to take account of "abuse-c:"
>  
> Thank you all for your work on this proposal!
>  
> Kind regards,
>  
> William
> on behalf of DB-WG co-chairs
>  
> 
> 




   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20170710/0ea643e7/attachment.html>