Details
|
|
|||
|
ID: |
AFPUB-2020-GEN-005-DRAFT01 |
Date Submitted: |
3 October 2020 |
|
Author: |
|
Version: |
1.0 |
|
Status: |
Expired & Archived |
Amends: |
CPM section |
Proposal
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:
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
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
Revision History
|
Date |
Details |
|
3 October 2020 |
Version 1: AFPUB-2020-GEN-005-DRAFT01 Initial Draft Posted to rpd |
AFRINIC Policy Impact Assessment
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
- 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?
- 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.
- 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."
- 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?
- 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.
