[ppml] Policy Proposal 2003-1a: Required Performance of Abuse Contact
John M. Brown
john at chagres.net
Tue Mar 11 14:38:51 EST 2003
Hmmm, so how does ARIN keep a IPv4 /32 from being used
on the global internet ???
Last I looked, ARIN has NO control, as repeatedly stated it
has NO control, and does NOT WANT CONTROL over the global
internet routing table.
Oh, wait, we can have them publish a database of "revoked"
space and then other service providers can build filters based
on that revoked space database.
Two phrases come to mind.
Not Scaleable.
Error Prone.
Folks, you are attempting to use the RIR's as the Police.Net
thats not their role. They have no statutory authority to be
the Police.Net. Thats what the FBI, State AG's office and
other places are for.
We all bitch about how <insert fav spam RBL> can't keep things
updated properly, take to long to remove fixed IP blocks, etc.
Do you REALLY think a RIR can do the job better ?? I certainly
dont, and dont even want them to think they can, or to try.
Its *NOT* their job.
Their JOB is simple. Allocate resources in a equal and fair manner,
make sure there aren't duplicate allocations, and report to ICANN and
IETF if they see things that might exhaust the resources they are
allocating.
Respectfully,
John Brown
> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On
> Behalf Of Owen DeLong
> Sent: Tuesday, March 11, 2003 10:37 AM
> To: Azinger, Marla; ppml at arin.net
> Subject: RE: [ppml] Policy Proposal 2003-1a: Required
> Performance of Abuse Contact
>
>
>
>
> --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