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

Owen DeLong owen at delong.com
Tue Mar 11 12:37:23 EST 2003



--On Tuesday, March 11, 2003 8:55 AM -0800 "Azinger, Marla" 
<marla_azinger at eli.net> wrote:

> Here are two more thoughts of my own that seem to go along the lines of
> this previouse response.
>
> 1.  Address valid for Legal Service:  I question whether any ARIN Proposal
> should start requiring "legal" delivery addresses.  I question this
> because as we all know this is a "sue happy" world these days. This type
> of information could easily become more of an instigator for unneccessary
> legal work that will cost any company more money than it should.  Plus,
> if someone really intends to sue a company or send legal notice of the
> type...they can get the needed information off of Government public
> records.  I really question whether this is something ARIN policy should
> be dipping into.
>
I can see both sides of this issue.  We'll see how people view it at the
meeting.  I could live with valid postal address, but, for now, I think
I'll leave it as is unless I get more feedback.

> 2.  If a resource is revoked under this policy, it shall be:  I think
> revoking IP's could be a very costly endeaver for ARIN.  If you were to
> revoke IP's from a company....that would effectively "restrict trade" and
> this alone would bring on "suing battles" between ARIN and the offending
> company.  Do we really want to encourage such an event?
>
Not at all.  This would be incorporated into the ARIN services agreement as
a material requirement of the contract.  ARIN provides resource allocation,
and the receiver agrees to meet the required conditions or risk having the
resource revoked.  This is fairly standard in business contracts.  If side
B makes a material breach of the contract, side A is free to stop providing
what they have agreed to provide.  It's not restraint of trade, it's 
contract
enforcement.  Since side B will have agreed to the contract, side B will 
have
very little grounds for suing side A because side A did what they said when
side B violated the contract.

Further, I don't think we can afford to avoid developing community standards
solely on the basis that we are afraid of being sued.  That is a slippery
slope, indeed.

Owen

> Regard
> Marla Azinger
> ELI IP Analyst
>
>
> -----Original Message-----
> From: Michael.Dillon at radianz.com [mailto:Michael.Dillon at radianz.com]
> Sent: Tuesday, March 11, 2003 2:35 AM
> To: ppml at arin.net
> Subject: Re: [ppml] Policy Proposal 2003-1a: Required Performance of
> Abuse Contact
>
>
>> 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