[ppml] Policy Porposal 2003-1c

[Owen DeLong]

Well, despite the support on the mailing list, this proposal fell very flat
in the meeting.  There was some support for the idea of trying to improve
the quality of data in the database and the possible requirement for the
abuse contact.

Negative comments included:
	+	Liability issues with enforcement provision
	+	Unwillingness of orgs. to accept enforcement provisions
		(generally, there seems to be no support for ARIN having the
		ability to revoke assignments under any circumstances period.)
	+	The policy is too detailed

As a result of this feedback, I believe there is still an issue to be
addressed here, and that said issue requires policy.  As such, I have
performed another rewrite on the policy below in the hopes of bringing
it more in-line with the desires of the community, while hopefully
preserving the ability for the policy to provide some effective steps
towards solving the problem.

For lack of a beter term, I'm calling this 2003-1c.

>>> Came from 2003-1
>>  Came from 2003-1a
>   Came from 2003-1b
     New for  2003-1c
>
>>>
>> 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 Service of Legal Process
>> 		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
>>
>>
>> Each ORG shall be required to meet the following standards with respect
>> to the performance and responsiveness of the  required ABUSE CONTACT(s).
>> 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.	Shall be capable of taking action or immediately contacting
 		a person capable of taking action to reasonably and
		effectively address an abuse complaint.

 	2.	Shall respond to the complaint as soon as
>> 		practicable with information on what actions, if any, 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 make an effort to facilitate communication
between the complainant and the ORG.

If ARIN is unable to contact the ORG in question, ARIN shall annotate the
applicable records in the database with an indication that this contact
was unreachable, and the date of last attempted contact shall be maintained
in the database as well.  This data shall also be made visible via whois.

ARIN shall publish a list of the IP Address and ASN records which have
unreachable contacts.  This list shall be published in such a way that
it can be retrieved by an automatic process, and shall be updated at least
once per week.  The list should also be published in a well defined format
which can be parsed by an automated system.  Each ASN entry in the list
should include the ASN number and the date of last contact attempt.
Each IP Address entry in the list should include the Prefix, Length,
and date of last attempted contact.  ARIN may add fields to the list
which it feels contain an operational benefit.  The list should not
include any entry for which some reachable contact has been verified,
even if some of the contacts are unreachable.

Lastly, ARIN shall verify all contacts for an ORG each and every time
the ORG submits a template or other request to ARIN.  In the event
a contact associated with the ORG is determined to be unreachable,
ARIN shall delay it's response to the request and inform the ORG in
question of the need for updated contact information.  The request
should remain on hold until the contact issues are resolved.  Requests
for contact information update shall not be delayed by this provision.

>>
>>>
>>> Argument in favor:
	In a multitude of circumstances, it can become necessary for
	the community to be able to reach parties responsible for
	the operation of a network or autonomous system.  In these
	cases, the generally accepted practice is to look those
	contacts up in WHOIS.  It has become quite clear in recent
	years that there are several entries in the database which
	do not contain valid contact information.  Some through
	accident and time, some through deliberate efforts to
	obscure identity or prevent accountability.  As such, this
	policy is intended to provide assistance and a friendly
	reminder to organizations whose data is not up to date
	while simultaneously making it harder to avoid
	accountability.

	While ARIN cannot take on an enforcement role without
	suffering significant risk of litigation and would have
	to expand it's corporate charter to do so, by publishing
	data and presenting to the community a list of resources
	which do not have valid contact information, the common
	internet tactic of "peer pressure" can be brought to bear
	on this issue.

>>>
>>> Problems:
>>
	It is entirely possible that the peer pressure advocated in this
	policy would never materialize or that it wouldn't be effective.
	However, this will not be worse than the current situation.

	There is a chance that the list publication process could be
	targeted for litigation.  However, since this is a list that
	simply says "We have been unable to reach the contacts for these
	resources", a simple factual statement, rather than a list
	which is set up for the express purpose of filtration, it is
	difficult to imagine the litigation having much success.
	(Your lawyer may vary).
>
>>
>>
>>> 3.  Proposed timetable for implementation:
>>>
Once the policy is adopted, ARIN should have 180 days to make the necessary
changes to the software and the database.  Once that is complete, the
policy should take full effect.  All portions of the policy which do not
require software changes should be implemented as soon as possible.