--- Begin Message ---
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@ripe.net> wrote:
>
>
> From: William Sylvester <william.sylves...@addrex.net>
> Subject: NWI-7: abuse-c implementation plan
> Date: 3 August 2017 at 21:12:06 GMT+2
> To: "db-wg@ripe.net" <db-wg@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
>
>
>
>
>
--- End Message ---
