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

[McBurnett, Jim]

Ok -
I think I like this as written..
BUT-- Am I understanding this correctly:
SWIP Process and ORG--
	If an organization has been SWIPd a Class C and their 
		Upstreams allow them to use Private ASN for the 
		advertising of said Class C- That ORG is not an ORG
		according to this Policy?
I am not saying this happens, but unless ARIN directly gives 
the Resource to the user, does this apply to them?

I am thinking of a SPAMMER in S Fla..... The IP block is not SWIPPED to them
and they have no ASN and don't seem fit this...

Not a problem for me.. I want to make sure we address ARIN Resposible ORGs and
not every JOE.. (we just can't do that)

Jim


> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com]
> Sent: Monday, March 10, 2003 8:06 PM
> To: ppml at arin.net
> Subject: Re: [ppml] Policy Proposal 2003-1a: Required Performance of
> Abuse Contact
> 
> 
> 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.
> 
> >
> 
>