Re: NEVERMIND! (was: ARIN Fraud Reporting Form ... )
On Oct 3, 2010, at 7:24 AM, "Ronald F. Guilmette" <rfg@tristatelogic.com> wrote:
I'm sitting here looking at your NRPM 3.6 and it says:
Unresponsive POC email addresses shall be marked as such in the database.
OK, Fine. So do you have a problem with ``marking those in the data base'' and specifically within the associated AS and IP block records? And if so why?
There is no problem with also marking resource records which have no valid POC's (even if not specifically stated by policy). It is an operational question not a resource policy question, and we generally handle those by informing the community of the plans to change practices through the ARIN consultation and suggestion process (https://www.arin.net/participate/acsp/index.html)
And if you have a problem with that, they please explain when and why you suddenly developed a problem with it, because clearly ARIN _was_ doing this before, at some point. (And it sure looks like you are NOT doing it now.)
I'd really like to know when and why ARIN stopped putting these annotations into the AS and IP block records associated with un-contactable POCs.
Can you just answer me that? I mean, you know, without directing my attention to some document which also doesn't answer the question?
Amazingly, you are my customer; i.e. I do indeed work for you and the rest of the community. So, I'm happy to try and address your questions (even if at times it appears more of an inquisition than constructive engagement...) The ARIN staff has been putting those notations in manually for net blocks which lack valid contacts, but doing so is not required by policy and has been resource intensive since the contact verification portion was manual. We are now looking (as a result of your fine suggestion) at automating this process of marking resource blocks with no valid contacts as an inherent part of the new automated POC verification process. /John John Curran President & CEO ARIN
In message <2FB9DEB1-95B5-4A26-8723-35F157F98807@arin.net>, John Curran <jcurran@arin.net> wrote:
There is no problem with also marking resource records which have no valid POC's (even if not specifically stated by policy). It is an operational qu estion not a resource policy question, and we generally handle those by informing the community of the plans to change practices through the ARIN consultation and suggestion process (https://www.arin.net/participate/acsp/index.html)
Ok, and so that part... the ``informing the community'' part... has been done already, correct? Because you folks _were_ installing those annotations before, right? So there is no new or additional bureaucratic hurdle to cross here, yes?
Amazingly, you are my customer; i.e. I do indeed work for you and the rest
Well, yes, actually, I knew that. But I'm not your _direct_ customer, and I'm aware of that, and what I think may be the probable implications of that also. (POTUS, in theory, also works for me, but as far as I can tell, he doesn't give two shakes about _my_ little opinion.)
of the community. So, I'm happy to try and address your questions (even if at times it appears more of an inquisition than constructive engagement...)
That's a fair comment, and I apologize for the tone. But I think you probably understand John and that (a) you _did_ elect to step into the conversation when I was already ranting and raving and also (b) that I'm mad as hell about what these low-life scum hijackers seem to be getting away with, and you just happen to be the closest target for my wrath at the moment (*and* also you're the only person I know who might have the ability to materially affect the outcome of this hijacking problem, long term).
The ARIN staff has been putting those notations in manually for net blocks which lack valid contacts, but doing so is not required by policy and has been resource intensive since the contact verification portion was manual.
OK. Yea. But follow along with me here for a moment... What you are doing now, which I think is rather obviously going to be highly resource-intensive, is you folks are, apparently, working to make contact with POCs, and failing that, you are putting the ``can't contact'' annotation into the POC records. OK, I grant you, this all may be labor intensive... although to the extent that you're doing the POC validation/verification just via e-mail, it would seem that even this part of the process could be rather entirely automated (but of course, that also would take work... to get that process automated). But now we are talking about something altogether different, i.e. sweeping through the AS and IP block records within your data base, and then, for each one, just doing a fetch on the assocated POC record(s) and then checking those to see if they _already_ have the ``cannot contact'' annotation in them, and then, if they do, just putting that other style of ``this may not be kosher'' annotation into the associated AS or IP block record. This is what I said I think I could do in Perl in a half an hour. This part certainly doesn't have to be labor intensive. It is readily amenable to complete automation, and if you are trying to do this part of the process in any sort of ``labor intensive'' manner, then I would argue that you aren't doing it right. (Of course, that's just one man's opinion, but it is an informed opinion, because I actually _am_ a software engineer, and I've successfully automated a lot of things, over time.)
We are now looking (as a result of your fine suggestion) at automating this process of marking resource blocks with no valid contacts as an inherent part of the new automated POC verification process.
OK, well, that is a profoundly Good Thing, in my opinion. And if I had any real brains, I'd quit now, while I'm ahead. But... I have to tell you that what you just said reminds me of a really funny story that an old friend of mine told me... Thirty years ago, I was working for some hardware company or another down in silicon valley, and my good friend Kurt was working for a little hole-in-the-wall company of about 15 people or so that built and sold PDP-11 clones, based upon DEC's LSI-11 chip. (He apparently actually witnessed this.) One day, a VERY irate customer of the company called up and asked to speak to the service manager... another guy at the commany named Everett, who was a good friend of Kurt's. So Everett gets on the phone with the irate customer, and the customer is screaming at him... ``God dammit! I sent in my board for RMA six weeks ago! So where the hell is it???'' So Everett says ``I don't know. If you'll hang on a minute, I'll go and check.'' So then Everett goes way way back in the back room, way behind the resoldering stations, back to the very back of the place, and there, underneath a dusty old work table with a bunch of unused crap old spare parts lying on top of it, Everett sees the customer's board, with the RMA tag on it, and the thing is covered in cobwebs, because it has been sitting there being ignored for so long. So what does he do? Well, Everett grabs the board, dusts it off, and gets back on the phone with the irate customer. But before he says anything, he motions to one of the mimimum-wage line workers to come over to where he is standing. So the guy comes over, and Everett points at the board. Naturally, the line worker looks at the board. So then Everett gets back on the phone with the irate customer and says ``Yea, we got a guy looking at that right now.'' :-) Sorry. For the last thirty+ years, every time somebody tells me that they are ``looking at'' something, I am reminded of that story. I'm going to try to shut up now, and I'm going to try to be a little patient, although it is quite obviously not my nature. But this whole hijacking problem quite obviously isn't going away anytime soon, and so I feel quite sure that the hijackers will give me a reason to keep watching and see if you've managed to follow through on getting these annotations into the AS and IP block records, where they'll do the most good. Obviously, my hope is that it won't take that long, because as I've also made clear, it doesn't appear to me to be a very hard problem, technically anyway. All that seems to be required is a willingness to go and do it. Regards, rfg
participants (2)
-
John Curran
-
Ronald F. Guilmette