[arin-ppml] Snarl: Using ARIN Contacts to report abuse.

[David Farmer]

I'm sorry, it wasn't my intent to ridicule you, I apologize if you feel I was.  
Actually, I commend you for following the RFC, you are ahead of many 
organizations by actually having abuse at .....  But, getting annoyed with 
people that don't use it when you haven't published it isn't very friendly 
either.  

Almost all the Internet Registries, allow for an Abuse POC now, I would 
recommend that you update all your registrations; Domains, Number 
Resources, Routing Registry, etc... with an Abuse POC.  If nothing else put 
it in a comment field if for some reason the registry doesn't support an 
Abuse POC.  

As others have pointed out the language in RFC 2142 isn't as strong as you 
would think.  I think I hear you saying that this seems redundant to publish 
Abuse POC info, maybe it is, but it defiantly makes it explicit, which I don't 
think the RFC does.

I recommend you include an Abuse POC, for the most part we only receive 
abuse complaints at our Abuse POC, but we do occasionally receive them 
addresses to our other POCs.  There is really nothing to be done about that, 
people are going to do what they do.  But, by publishing our Abuse POC 
which is "abuse at umn.edu" we only rarely get Abuse related complaints to 
our other POCs.

Personally, I think that is it on this subject unless you think that there is 
some kind of policy needed by ARIN related to this.

On 3 Nov 2008 Stewart Dean wrote:

> OK, but.
> What is wrong with sending something to abuse, if only a copy?  This is 
> the canonical forever way to do it, if only a copy; it's in the 
> dad-cussed RFC whatever...not that anybody follows them, gripe, gripe. I 
> know, we don't really need standards, everyone whould just wing it as 
> best he or she sees fit.
> 
> When I came to make the change from people to symbolic POCs (because our 
> IT head changed), I just updated the the existing POCs 
> individually...there was no abuse POC in our long extant whois listing.  
> It might help if the POC update template from indicated a list of POC 
> roles as a hint.  This a gotcha.
> 
> I *really* try to get things right, and this feels gratuitous.
> 
> I'll just sit over here in my corner and munch more sour grapes........
> 
> 
> David Farmer wrote:
> > I looked up your Org entry, you should add an Abuse POC handle, you only 
> > have an Admin POC Handle and 2 Tech POC Handles.  By not having an 
> > abuse handle your not telling people that you want abuse complaints sent 
> > somewhere else.  Without an Abuse POC I would probably send abuse 
> > complaints to your Tech POC Handles, because if you don't publish your 
> > abuse contact information why would I assume you even have one?
> >
> > I suspect if you publish an Abuse POC you will see abuse complaints go 
> > there.
> >
> > "Abuse POC Handle: Indicate the ARIN POC handle of a contact 
> > responsible for handling operational aspects of the acceptable or 
> > appropriate uses of the allocated network. The abuse POC may not make 
> > modifications to the allocated network registration. "
> >
> > On 3 Nov 2008 Stewart Dean wrote:
> >
> >   
> >> I am increasingly seeing that abuse-related comments are going to our 
> >> ARIN whois info contacts instead of abuse@<domain>. ...this seems to be 
> >> the new thing....I guess they figure that this way they'll get someone, 
> >> since these addresses are explicitly listed, where abuse@<domain> is one 
> >> of the implicitly (by RFC standard) required, but not always incarnated
> >>
> >> Damn.  This is one of those expedient, but wrong way to do things, but 
> >> everyone is adopting it.
> >>
> >> It's fortunate that I made the contacts symbolic aliases (iptech, 
> >> ipadmin, ipbill) instead of actual people's names.  At least this way we 
> >> can send it to multiple people...otherwise, if it was going to an actual 
> >> user, we'd have to rely on that person to fwd..........which wouldn't 
> >> happen when they were on vacation. 
> >>
> >> <snarl>
> >> -- 
> >> ==== Once upon a time, the Internet was a friendly, 
> >> neighbors-helping-neighbors small town, and no one locked their doors. 
> >> Now it's like an apartment in Bed-Stuy: you need three heavy duty 
> >> pick-proof locks, one of those braces that goes from the lock to the 
> >> floor, and bars on the windows....
> >> ==== Stewart Dean, Unix System Admin, Bard College, New York 12504 
> >> sdean at bard.edu voice: 845-758-7475, fax: 845-758-7035
> >>
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed to
> >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net if you experience any issues.
> >>     
> >
> >
> >
> > =======================================================
> > David Farmer				     Email:	farmer at umn.edu
> > Office of Information Technology
> > Networking & Telecomunication Services
> > University of Minnesota			     Phone:	612-626-0815
> > 2218 University Ave SE			     Cell:		612-812-9952
> > Minneapolis, MN 55414-3029		     FAX:	612-626-1818
> > =======================================================
> >   
> 
> 
> -- 
> ==== Once upon a time, the Internet was a friendly, 
> neighbors-helping-neighbors small town, and no one locked their doors. 
> Now it's like an apartment in Bed-Stuy: you need three heavy duty 
> pick-proof locks, one of those braces that goes from the lock to the 
> floor, and bars on the windows.... ==== Stewart Dean, Unix System Admin, 
> Bard College, New York 12504 sdean at bard.edu voice: 845-758-7475, fax: 
> 845-758-7035



=======================================================
David Farmer				     Email:	farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-0815
2218 University Ave SE			     Cell:		612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-1818
=======================================================