|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Operational Issues with 69.0.0.0/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 69.0.0.0/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 70.0.0.0/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
|