Proposal

1. Summary of the problem being addressed by this proposal

The current policy doesn’t imply the obligation to register an abuse contact and specifies a format for personal communication and for “automatic reporting”, which compared to other RIRs becomes confusing, as a single email will be more efficient, as at the end, reports get copied to both emails.

As a result, some resource-holders may not have this contact information registered and up to date for their resources. In fact, there are even cases of non-existent mailbox or one that is not actively monitored.

In practice, this contact becomes ineffective to report abuses and generally gives rise to security issues and costs for the victims. This is also contradictory with RSA, that states that information in databases must be accurate. This policy ensures that this can be automatically and periodically verified by AFRINIC, without entering in the operational details of how to do it. In fact there is an AFRINIC activity (https://afrinic.net/stats/contact-update) that aims for verification of contacts, however it has only reported for 2017. Again, this proposal, ensures that this activity is done in an automated fashion (as much as possible), saving cost to the membership and the community.

This proposal aims to solve this problem and ensure the existence of a proper abuse-c contact and the process for its utilization, which is more uniform across all the RIRs, in order to facilitate cross-region abuse reporting.

Existing policy references to a “Best Practice Paper”, which is not deemed as mandatory and in fact, is not being used by the community. This proposal doesn’t change the scope of that document, and in fact, a link between the few existing IRT objects and the new one should be automatically established.

This way, AfriNIC abuse contact will be in line with other RIRs. APNIC, for example, is now using the IRT, but since an equivalent proposal has been accepted, an automated “link” (alias or pointer) to the pre-existing IRT will be created, so abuse-c and abuse-mailbox prevail.

There is no need to delete the other optional data today included in the IRT, it is an operational AFRINIC decision how to handle the transition. This policy just ensures that abuse-c and abuse-mailbox are available and verified periodically.

2. Summary of how this proposal addresses the problem

The Internet community is based on collaboration. However, in many cases this is not enough and we all need to be able to contact those LIRs that may be experiencing a problem in their networks and are unaware of the situation.

This proposal creates a new section in the Policy Manual to solve this problem by means of a simple, periodic verification, and establishes the basic rules for performing such verification and thus avoids unnecessary costs to third parties that need to contact the persons responsible for solving the abuses of a specific network.

The proposal guarantees that the cost of processing the abuse falls on the resource-holder whose client is causing the abuse (and from whom they receive financial compensation for the service), instead of falling on the victim, as would be the case if they had to resort to the courts, thus avoiding costs (lawyers, solicitors, etc.) and saving time for both parties.

For this, the abuse-c attribute becomes mandatory in the “aut-num”, "inetnum" and "inet6num" objects, as well as in any others that may be used in the future. This attribute is an abuse contact, which must contain at least the "abuse-mailbox" attribute.

The proposal is expected to be implemented in 90 days, to be confirmed by AfriNIC, a reasonable time frame to allow both the staff to develop the tool and the members to update their abuse-c contacts.

3. Proposal

3.1 Amending 8.0 of the CPM, as follows: 

3.2 Additional information:

If this proposal reaches consensus, to comply with it, AFRINIC must rename mnt-IRT to abuse-c. It is an operational AFRINIC decision if an alias (pointer, duplicated attibute, or any other alternative) to mnt-IRT is kept and for how much time (transition period), in order to facilitate the search in whois for the same information, regardless if looking for abuse-c or mnt-IRT. It is an operational AFRINIC decision to keep and for how much time, the IRT or delete it, as well as the rest of the actual information in the IRT. AFRINIC will also decide how to better update the actual guidelines (https://www.afrinic.net/library/membership765-abuse-policy-bcp) or if they aren’t longer needed. This is done in order to assimilate the IRT to the majority of the RIRs where it is abuse-c.

As a matter of clarification, the “initial” and “escalation” validation periods may be modified by AFRINIC, if deemed appropriate, provided it informs the community of its motivation for doing so. For example, in the implementation phase, the periods could be extended, and adjusted as a higher percentage of contacts become accurate.

Similarly, the frequency of the periodic validation can be modified if AFRINIC deems this appropriate and informs the community of its reasons for doing so.

For example, a single validation might be done in the first year to facilitate adherence to the policy. The number of annual validations could increase over time, perhaps becoming quarterly, with the aim of improving the quality of the contacts.

 4. References            

An equivalent proposal has been accepted in APNIC (already implemented) and is under discussion in the ARIN, LACNIC and RIPE regions.

Revision History

Revision History