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

[Mury]

I haven't decided if I like this policy or not.  I certainly appreciate
what it is intending to accomplish, but with my indecision put aside one
things bothers me more than other parts.

If "RESOURCES" are revoked, how is ARIN going to handle those resources?
Will they forever be kept on a list of "unusable" resources, thus allowing
the offender in essence to continue using them.  Or will they be recycled
to a new member, possibly making that new member's life horrible if the
offending member is still attempting to utilize those resources.

I guess it gets down to the point that ARIN is basically a records keeping
shop.  They tell a new settler that they indeed own a parcel of land, but
they can't keep the bandits away.  Where is ARIN going to get its guns
from?  A group of backbone providers who agree to enforce ARIN's rulings?
Lawyers?

I'm not really expecting an answer.  I'm really just wondering how
effectively ARIN can revoke something.

Mury

On Mon, 10 Mar 2003, Owen DeLong wrote:

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