North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Operational Issues with 18.104.22.168/8...
On Fri, Dec 06, 2002 at 12:14:51PM -0500, James Smith wrote: > One would think that operators not updating filters to permit > properly allocated space IS an operational issue. To quote a friend "public shaming will only go so far". At some point, you have to communicate to your customers and to the customers of the broken networks that the vendor shouldn't be used. This is one case where no attempt at finger-pointing could even remotely be made; when a customer/whoever protests, offer to conference in with $broken_network's technical people and have them admit they're broken. It's the same approach needed for fixing wildly random deaggregation. Actually *talking* to people works. I think I already pointed to the one hole that might be ARIN's problem to fix, but to be blunt about it... I wouldn't expect NO entry for properly activated/allocated space. Regardless if you choose the RIPE approach, the APNIC approach, or come up with a new one, the values returned for queries should at least differentiate from "space over which I have authority" and "space over which I do not have authority": prompt> whois -h rr.arin.net 22.214.171.124/8 % ARIN Internet Routing Registry Whois Interface % No entries found in ANS, ARCSTAR, ARIN, BCONNEX, % BELL, CANET, CW, FGC, KOREN, LEVEL3, POC, RADB, RIPE and VERIO database. prompt> whois -h rr.arin.net 126.96.36.199/8 % ARIN Internet Routing Registry Whois Interface % No entries found in ANS, ARCSTAR, ARIN, BCONNEX, % BELL, CANET, CW, FGC, KOREN, LEVEL3, POC, RADB, RIPE and VERIO database. prompt> -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE