Formal introduction on PPML on 4 March 2003This policy proposal was amended by the policy author on 10 March 2003 and 25 March 2003 Public Policy Mailing List
ARIN Public Policy Meeting:ARIN XI
ARIN Board of Trustees:BoT Meetings
Revisions:View previous version
1. Statement of proposed Policy:
For the purposes of this policy, the following terms shall apply:
An organization or organizational unit which receives one or more resources from ARIN, whether by allocation or assignment. In either case, the ORG in question shall bear full responsibility under this policy for meeting the requirements thereof and bearing any consequences of failure to meet said responsibilities.
This shall apply to the ORG to which ARIN directly allocated the resource, or to another ORG, which, has received from the previous ORG a transfer of the resources under ARIN's transfer policies. A simply SWIP of an assignment to an ORG which does not have a contractual relationship with ARIN shall not constitute such a transfer.
The appointed POC units which have authority and access to make changes to the ARIN held data regarding a resource owned by a particular ORG.
A point of contact, whether human or role.
This policy makes no effort to define Abuse. It is the opinion of the author of this policy that such a definition should come from the IETF and not from ARIN. It is the intent of this policy to set standards for the response required from an abuse contact without addressing the actions required by said contact. Again, it is the opinion of the author that said actions are outside of ARIN's scope and belong within the IETF.
An ABUSE contact is a POC for an ORG which is associated with an ARIN issued resource as the POC responsible for addressing issues of abuse originating at or from the resource in question.
In the case of ARIN, resources currently include ASNs and IPv4 and IPv6 address ranges which are allocated or assigned to registered ORGs.
An autonomous system number
Internet Protocol Version 4
Internet Protocol Version 6
For any given RESOURCE in the ARIN database, ARIN shall require at least one and allow multiple ABUSE CONTACTS to be listed. For at least one ABUSE CONTACT in each resource, ARIN shall require and maintain at least the following information:
Individual or Role
If Individual, full name
Address valid for Legal Service Must support physical delivery, registered mail, or both, and shall indicate which is acceptable.
A list of "normal business hours" specified in terms of the time zone applicable to the address in item 3 or in UTC, with an indication of whether DST should be considered. These hours should comprise at least 30 hours per week.
A phone number
A URL where the ORG maintains a web site listing it's ABUSE POLICIES.
Each ORG shale be required to meet the following standards with respect to the performance and responsiveness of the required ABUSE CONTACT, and each ABUSE CONTACT which contains all of the data specified above. In cases where the language cannot be logically applied to a ROLE account, it shall mean all individuals assigned by the ORG in question to read the email or answer the phone calls to the addresses/numbers listed in the ABUSE CONTACT.
With the exception of sudden events of large call volume, shall staff adequately to have live humans answer calls to the listed abuse contact phone number during the hours indicated in the contact record.
Shall have a human being read and respond to abuse complaints received by email within 48 hours of receipt (for complaints received Sun-Thu), and, within 96 hours for complaints received Fri-Sat.
Shall be capable of taking action or immediately contacting a person capable of taking action to stop any reported abuse which is in violation of any of the following:
Any definition of network abuse published by the IETF. (This shall not be construed to include any minor failure to comply with an RFC, but shall only apply to things the IETF has specifically defined as abuse).
Any definition of network abuse determined by the ORG to be abuse in any of their own published AUPs.
Any definition of network abuse which meets all of the following criteria:
Is defined as abuse in a policy published on the complaining networks ABUSE CONTACT URL.
Can be defined in terms that would allow most routers to block the abuse in question through the use of packet filters or other commonly available technology.
(Commonly available technology for this purpose means a feature that is present and can be reasonably implemented in the majority of backbone router types in use on the Internet at the time of complaint.)
- Is not a standard response to traffic being received from the complaining network.
It should be noted that this requirement is for the capability to take action to be present. It does not require the individual in question to take the desired action. That matter is between the parties. The ARIN agreement requires the contact to be available to respond.
Shall take appropriate action to stop abuse identified in the previous item as soon after receiving the complaint as practicable.
Shall respond to the complaint as soon as practicable with information on what actions are being taken to stop the abuse.
Further, if an entity believes an ORG is not living up to the requirements set forth in this policy, they should be able to notify ARIN of the issue, including detailed documentation of the efforts made to contact the ORG and the results thereof. Any complaint received by ARIN which does not include the required information should receive only a form-reply from ARIN indicating what information is required to verify the complaint.
In the event of a valid complaint, ARIN shall attempt to contact the ORG in question and notify them of the complaint. If ARIN is able to contact the ORG in question, ARIN should wait two weeks and contact the complainant. If the complainant is satisfied, no further action is required by ARIN. If the complainant is not satisfied, ARIN staff shall make a determination whether the complaint meets the definitions of abuse in 3 above. Further, the ARIN staff shall make a determination if the response and actions taken by the ORG in question meet the requirements of the policy. If the ARIN staff determines that the complaint meets the requirements and that the response of the ORG in question has not met the requirements of this policy, the ARIN staff shall inform the ORG of these facts, specifically indicating what additional response and/or action is necessary to comply. The ORG shall then have 5 business days or a longer reasonable time as determined by the ARIN staff to comply. If the ORG remains out of compliance, then the ARIN staff shall revoke each and every specific resource listed in the complaint and determined to be out of compliance with this policy.
If a resource is revoked under this policy, it shall be referred to the ARIN ABUSE COUNCIL for final determination. The ORG in question shall have 30 days to present their side of the issue to the council in written form via email. The ORG in question may at any time prior to the 30 days indicate that they have submitted all desired information and terminate the 30 day period 24 hours after sending that email. After the 30 days has expired or the ORG has terminated the 30 day period as described, the ABUSE COUNCIL shall have 10 days to make a final determination on the revocation. The ABUSE COUNCIL may affirm the revocation, in which case, it becomes permanent. The ABUSE COUNCIL may overturn the revocation, in which case, the resources are to be immediately returned to the ORG in question. The ABUSE COUNCIL may decide to grant the ORG in question an extension for compliance. In that case, the council shall set a date by which the ORG must comply. The resource(s) will be immediately returned to the ORG in question. If, at the date in question, the ORG is determined by ARIN staff to still not be in compliance, the resources shall again be revoked. The ORG may again appeal this decision to the ABUSE COUNCIL as described.
The ARIN BOARD shall nominate candidates to participate in the ABUSE COUNCIL. The ABUSE COUNCIL shall have 5 members. Each member shall be for a 2 year term. The first time, 3 members shall have 2 year terms, and 2 shall have 1 year terms. The ARIN BOARD shall nominate not less than two, nor more than three times the number of vacant seats. In the first election, the three candidates receiving the most votes shall be elected for 2 years. The community at large shall be allowed to vote, similar to the ASO AC election process. The election shall be conducted as a "Vote for no more than N" where N is the number of available seats (5 the first time, 2 the following year, 3 the year after, and so on). The ABUSE COUNCIL shall not be required to conduct physical meetings, and there shall be no compensation paid to the ABUSE COUNCIL by ARIN.
If a complaint comes up against an ORG to which an ABUSE COUNCIL member has ties which could create a conflict of interest, then that members place on the ABUSE COUNCIL shall be filled by a member of the ARIN BOARD chosen at random with respect to that specific complaint.
The ARIN BOARD shall serve as the ABUSE COUNCIL until such time as one can be elected. In no event shall there be less than 30 days from the public release of all candidates statements and nominations to the close of the voting. The ARIN BOARD shall set the annual election date, and shall nominate candidates each year at least 60 days prior to the election date. Voting shall be conducted for not less than 30 days leading up to the election date.
The ABUSE COUNCIL changes shall take effect 5 days after the election date.
2. Argument for the proposal and general discussion of the issue.
When trying to resolve issues of abuse, three things are important:
Being able to pass the abuse information along to a meaningful contact at the originating ORG.
The originating ORG taking appropriate action to stop the abuse.
Meaningful contact from the originating ORG explaining what was done.
Many ORGs today have built elaborate automated systems for handling abuse complaints. It is not uncommon for these systems to fail to meet items 1 and 2 above. It is almost unheard of for them to meet item 3. It is time for us to move the Internet beyond the idea that the victims of abuse should just have to accept those costs as part of being connected. The organizations where abuse originates must be required to address abuse originating from resources within their responsibility.
This policy primarily addresses items 1 and 3. It is limited in it's ability to meet item 2 by the following factors:
- No clear definition of what constitutes abuse. Although there is some definition included in this policy, that is intended to be overly vague and should only be used to exclude acts which are _NOT_ abuse from triggering revocation.
- No policy or guidance from IETF or ICANN on abuse
- The registries have not been assigned an abuse-related role other than the maintenance of contact information for resources they allocate.
- Significant additional controversy in the community regarding the definition of abuse and who determines the definition of abuse.
As such, this policy attempts to make a strong first step by addressing items 1 and 3 as completely as possible, facilitating a better effort towards item 2 by the parties involved.
Argument in favor:
When an automated system fails, it becomes important to be able to reach a human being capable of intervening or contacting an intervener. It is OK if the POC information (address, phone number, etc.) is a work number, or NOC, or even a switchboard, as long as it is a point of contact which leads to a real person with some ability to close the loop. It does not have to lead to a specific real person, but it must be possible to engage human intervention through this process.
Most of the objections to the original version of this policy represented the need for ROLE accounts and the desire not to release personal information. I think this amended proposal addresses both of those concerns. Other concerns raised were the definition of abuse. While this policy does not define abuse, I think it provides decent metrics for determining abuse through the IETF and through each networks AUP. Further, it shifts the definition of abuse to the perspective of the receiving network, allowing each network to define what traffic they are willing to accept in a public and accessible manner. Further, it avoids overly burdensome definitions of abuse by only requiring originating ISPs to take action to stop abuse if the policy defines abuse in terms which reasonably allow the ISP to configure that definition into their routers to prevent the origination of such abuse, and, then, only after the abuse has occurred and generated a complaint.
Additionally, it avoids taking any action based on abuse. It requires both abuse and a failure to meet a contractual obligation to maintain valid abuse contacts in order for an ORG to have their resources revoked. Hopefully this provides a balanced approach to requiring valid contact information. Given valid contact information, the parties involved should be able to resolve abuse situations in good faith. In any case, the RIRs role is limited to facilitating the contact and they have no involvement in the actual determination of abuse or it's resolution.
3. Proposed timetable for implementation:
Once this proposal is ratified, ARIN should update it's registration services agreement to reflect the new policy within 30 days. Existing ORG and other bodies should receive notification of the change and the requirement to comply during that same period. They should be required to comply within 90 days of the date the notification is sent to the existing ADMIN-C.
After that time has elapsed, ARIN staff should be expected to investigate and take further appropriate action on any complaint received about lack of appropriate ABUSE CONTACT(s) in any resource record.
Appropriate action is left to the discretion of the ARIN AC, but should include ARIN staff contacting the ORG in question by any means reasonably available to ARIN, and, possibly revoking resources found to be out of compliance.