[ppml] Policy Proposal 2003-1a: Required Performance of Abuse Contact

[Owen DeLong]

There has been some good discussion and feedback in response to proposal 
2003-1.

As a result, I have pretty much rewritten the proposal.  What little remains
of the original proposal is prefixed with "> " quoting.  Hopefully, this new
version, which I offer as a proposed amendment, will address the original 
issue
and most of the feedback I have received.  I hope to further refine this so
that we can go into the public policy meeting with rough consensus around
a policy which will facilitate significant improvement around this issue.

Owen

>
Policy Proposal 2003-1a: Required Performance of Abuse Contact
>
> 1. Statement of proposed Policy:
>
For the purposes of this policy, the following terms shall apply:

ORG	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.

MAINTAINER
	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.

POC	A point of contact, whether human or role.

ABUSE CONTACT
	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.

RESOURCE
	In the case of ARIN, resources currently include ASNs and IPV4
	and IPV6 address ranges which are allocated or assigned to
	registered ORGs.

ASN	An autonomous system number

IPV4	Internet Protocol Version 4

IPV6	Internet Protocol Version 6

Proposed Policy

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:

	1.	Individual or Role

	2.	If Individual, full name

	3.	Address valid for Legal Service
		Must support physical delivery, registered mail, or both,
		and shall indicate which is acceptable.

	4.	Email Address.

	5.	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.

	6.	A phone number

	7.	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.

	1.	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.

	2.	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.

	3.	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:

		A.	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).

		B.	Any definition of network abuse determined by the
			ORG to be abuse in any of their own published AUPs.

		C.	Any definition of network abuse which meets all of the
			following criteria:

			1.	Is defined as abuse in a policy published
				on the complaining networks ABUSE CONTACT
				URL.

			2.	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.)

			3.	Is not a standard response to traffic being
				received from the complaining network.

	4.	Shall take appropriate action to stop abuse identified
		in the previous item as soon after receiving the complaint
		as practicable.

	5.	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.
>
> Issue:
	When trying to resolve issues of abuse, three things are
	important:

	1.	Being able to pass the abuse information along to a
		meaningful contact at the originating ORG.

	2.	The originating ORG taking appropriate action to
		stop the abuse.

	3.	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.

>
> 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.
>
> Problems:

	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.


> 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.

>