General Abuse Contact (Draft-1) | Expired & Archived

1. Summary of the problem being addressed by this proposal

The current policy fails to improve data accuracy in the WHOIS database and compliance for what concerns addressing issues. It does not support members actively using the object for declaring abuse contact information. Most importantly, it does not decrease the number of abuse emails that are directed to AFRINIC tickets, which means that it is not operationally smooth.

Section 8.X does not offer a valid method on how to host reports about not working and not specific objects.

It is inefficient to treat the abuse-c separately from the other mandatory contact - admin-c or tech-c.

2. Summary of how this proposal addresses the problem

The proposal removes entirely section 8.X. because it mostly gives AFRINIC a control role that is out of its scope.

The proposal aims to include abuse-c as part of whois registration by adding it under section 7.5.1 "Registering contact persons" which already covers the other mandatory contact - admin-c or tech-c.

This addition will allow the system to return to errors if someone creates an object without the mandatory contact attribute, which means that if something goes wrong (creating an object without the mandatory contact attribute) while the members report abuse, the system will return an error to inform the user. If the policy has specific parameter requirements, the system will also report an error if they are not correct.

3. Proposal

3.1 Amending Section 7 and 8 of the CPM, as follows:

Current	Proposed
7.5.1 Registering contact persons Administrative and technical contact persons must be registered for each ASN assigned. The registered administrative contact ('admin-c') is the person responsible for the ASN and should generally be someone who is physically located at the site of the AS. The technical contact ('tech-c') need not be physically located at the site of the AS but must be a person who is responsible for the day-to-day operation of that AS.	7.5.1 Registering contact persons Administrative and technical contact persons must be registered for each ASN assigned. The registered administrative contact ('admin-c') is the person responsible for the ASN and should generally be someone who is physically located at the site of the AS. The technical contact ('tech-c') need not be physically located at the site of the AS but must be a person who is responsible for the day-to-day operation of that AS. The abuse contact("abuse-c") should be a person who can handle abuse issues on the network, and it is for the network to communicate with each other on abuse issues.
8.1 Introduction This policy specifies a dedicated object that shall be used as the preferred place to publish abuse public contact information within the AFRINIC service region. The mentioned object can be referenced in the inetnum, inet6num and aut-num objects in the AFRINIC whois database. It provides a more accurate and efficient way for abuse reports to reach the correct network contact 8.2 Policy details: To make available a new or use an already existing whois database object that implements the following properties: A unique reference by inetnum, inet6num and aut-num Contains 2 email attributes: 1. "e-mail:" for personal communication 1. "abuse-mailbox:" for automatic report handling The object should be accessible through the WHOIS protocol. AFRINIC to publish a Best Practice Paper that encourages all members actively to use the object for publishing abuse contact information. 8.3 Advantages and disadvantages of the policy 8.3.1 Advantages 1. Networks will be able to supply their own, direct contact information for abuse departments. 1. Abuse complaints will not be sent to the "wrong" contact anymore. 1. This permits greater administrative and operational flexibility, and faster abuse handling will be possible. 8.3.2 Disadvantages This object, like all other existing objects, will face the data accuracy problem. This policy aims to address the issue of a missing place for abuse contact information and will not improve data accuracy in the whois database. Nevertheless, it is suggested to AFRINIC to offer a way to receive reports about not working or not accurate objects.	REMOVE Section 8 entirely

Revision History

Date	Details
3 October 2020	Version 1: AFPUB-2020-GEN-005-DRAFT01 Initial Draft Posted to rpd

AFRINIC Staff Assessment

1) Staff Interpretation & Understanding of the proposal

This proposal removes Section 8 related to abuse contact information from the Consolidated Policy Manual (CPM). It further proposes an amendment to Section 7.5.1 of the CPM.

AFRINIC notes that Section 7.5.1 of the CPM covers the registration requirements of an ASN in the AFRINIC WHOIS database. Therefore AFRINIC understands that this proposal makes abuse-c mandatory in an aut-num object on its WHOIS database. . Therefore, this proposal aims to ensure that all ASNs registered to AFRINIC Members in the AFRINIC WHOIS database shall contain an abuse -c.

Currently,1738 Members hold a total of 1882 ASNs

As per the proposal, The abuse contact ("abuse-c") should be a person who can handle abuse issues on the network, hence we interpret that the abuse-c shall refer to a person object on the WHOIS database. IPv4 and IPv6 resources registered on the AFRINIC WHOIS database are not impacted by this proposal. The proposal is silent as to what happens to the IRT objects (27 of them) in use by the Resource Members and through which they receive abuse complaints reports.

2) AFRINIC Recommendations

None

3) AFRINIC Clarification Requests

1. Author, to clarify if the removal of Section 8 of the CPM implies that the IRT object should be deprecated from the AFRINIC whois database?

2. The proposal as worded will not ensure that inet(6)nums will not contain an abuse-c. Author to clarify if this is what the proposal aims to achieve.

3. The proposal as written contains some statements that are not comprehensible and can easily lead to erroneous interpretations & implementation concerns as follows "Section 8.X does not offer a valid method on how to host reports about not working and not specific objects." , "This addition will allow the system to return to errors if someone creates an object without the mandatory contact attribute, which means that if something goes wrong (creating an object without the mandatory contact attribute) while the members report abuse, the system will return an error to inform the user. If the policy has specific parameter requirements, the system will also report an error if they are not correct." , "The abuse contact("abuse-c") should be a person who can handle abuse issues on the network, and it is for the network to communicate with each other on abuse issues."

4. Authors mention that "The current policy fails to improve data accuracy in the WHOIS database and compliance for what concerns addressing issues." How will this proposal as written improve data accuracy in the WHOIS database and compliance for what concerns addressing issues?

5. Can an aut-num have more than one abuse-c contact? This clarification is required for the purpose of determining if the abuse-c on an aut-num object will be:

abuse-c: [mandatory] [multiple] [inverse key] OR abuse-c: [single] [multiple] [inverse key]

4) Impact on Registry Functions

The statistics of the number of abuse reports that are handled by AFRINIC staff are as follows. They consist of abuses related to IP addresses (IPv4 mostly)

Month	Jun-20	Jul-20	Aug-20	Sep-20	Oct-20	Nov-20	Dec-20	Jan-21	Feb-21	Mar-21	Apr-21	May-21
No. of Tickets	557	1054	129	100	61	81	112	117	86	133	106	122

Queries on whois database in regard to these IP addresses will not display the abuse emails to which abuse reports can be reported.

4.1 Processes

• Process reviews will be required to ensure that abuse-c information is received for the ASNs.

• A proper migration plan for those members currently using IRT in case the authors state that the proposal's removal of section 8 entails deprecating IRT.

4.2 Procedures

Member Services procedures to be amended to include abuse-c contact

4.3 Documentation

Member Guidebook and website documentation to assist members in adopting the abuse-c contact

4.4 Systems - RPKI

No impact

4.5 Systems - WHOIS

A new mandatory attribute abuse-c will be required for aut-num objects.

IRT object phased deprecation(if clarified by authors)

4.6 Systems - MyAFRINIC

Coding updates to add the abuse-c to the ASN forms

4.7 Systems - Infrastructure

No impact

4.8 Systems - Netsuite

No impact

4.9 Systems - NMRP

Coding updates to add the abuse-c for applicants to provide.

5. Impact on Resource Holders

1738 Resource Members that have ASNs delegated to them will be requested to comply with this policy by providing their abuse-c contact.

6. Financial Impact

No impact

7. Legal impact

The legal Team advises on the need for compliance with the Data Protection Act (DPA) in case personal data of the abuse-c are intended to be published on the WHOIS database. Alternatively, in order to ensure full DPA compliance, the authors may consider specifying the need for role-based email addresses so that no individual (data subject) may be identified through email addresses being adopted for that purpose.

8. Implementation timelines

The proposal as written contains a number of an unclear implication that needs to be clarified. If implemented as drafted, would result in operational issues based on varying interpretation.