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

Michael.Dillon at radianz.com Michael.Dillon at radianz.com
Tue Mar 11 05:34:42 EST 2003


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

Don't back off so vigorously. Here's an attempt at some better wording:

Given that the network is a shared resource, it is inevitable that some 
activities on the network will be viewed as network abuse by other users 
of the network. We make no attempt to define abuse here since that is 
better left to other forums. ARIN's only interest is to facilitate 
communication between the various parties who are using the network. To 
that end, this policy specifies the contact information that each 
organization MUST publish.

I'm not sure whether I should have used the IETF form of "MUST" in that 
wording, especially since this isn't found in other ARIN policies. 
However, the idea of using specific wording to make it a very clear 
distinction between what is mandatory and what is recommended may be a 
good idea to adopt. Read RFC 2119 for more info.

>                3.              Address valid for Legal Service

How about "Address to be used only to serve legal documents".

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

Too complicated. It should just indicate normal business hours in local 
time and identify the timezone offset from GTM. Assuming North American 
sites, everybody has a business day that overlaps everybody else at one 
end of the day or other, even the Aleutian islands (GMT -10 no DST) and 
Newfoundland (GMT -3.5 uses DST) make it just barely. But if you are 
thinking of the rest of the world, DST rules are not the same everywhere. 
In fact languages and legal systems are also different so let's not go 
there.


>                6.              A phone number

Specify that this is a toll number. An 800 number that is usable in the 
USA cannot normally be used from within Canada and vice versa. And a 
regional network probably is only paying for a regional 800 number which 
means it won't work nationally. 

>                7.              A URL where the ORG maintains a web site 
listing it's ABUSE
>                                POLICIES.

Sounding more like a job for LDAP every day...


>Each ORG shale be required to meet the following standards with respect

I think this whole section is outside of ARIN's mandate because it is 
defining how the members do business and therefore could be viewed as 
restraint of trade.

>If a resource is revoked under this policy, it shall be referred to the
>ARIN ABUSE COUNCIL for final determination. 

This costs money. Before going into great detail about how such a 
hypothetical function will operate you should get some consensus on 
whether or not such a function should exist. This also gets way out of 
scope of a policy for maintaining some contact info.

If ARIN ever did create an ABUSE COUNCIL, I doubt it would happen like 
this. If there really is a need for such a council, it would be better to 
start a working group to do some investigations of the need, define the 
scope, and draft some guidelines for how the ABUSE COUNCIL would operate. 
Then, only if all of this was successful and met with broad support, would 
you get serious consideration from the ARIN board and AC.

--Michael Dillon





More information about the ARIN-PPML mailing list