jcurran at arin.net
Sun Jan 9 18:33:18 CST 2011
On Jan 9, 2011, at 6:30 PM, Jeff Wheeler wrote:
> I appreciate you taking time to respond to this while on vacation.
> However, I think we all know that your response is not a "here is how
> you tell us what to do," it's a "here is our cop-out response to make
> an incredibly simple fix either never happen, or take six months to
> make it through the ARIN process."
As it turned out, I'm back from vacation but thanks for the thought.
My reason for responding is simply to make sure that ARIN is doing
what the community wants. I won't deny that this may take some time
depending on exactly what is involved, but in my mind that is far
better than not fixing the situation.
> If you truly do not understand the posts regarding this matter, I will
> summarize them for you very simply:
> 1) ARIN IRR is a tool that has operational impact; service providers
> use it to build prefix-lists automatically, and if the data that
> underlies those prefix-lists is corrupted, networks that use the ARIN
> IRR will see their transit providers stop accepting their BGP
> announcements overnight. This is not a "some database might be
> inaccurate but it's okay," problem; it is an operational problem.
> Some peoples' networks depend on that data not becoming corrupted.
> Specifically, every network that uses ARIN IRR.
Thanks; I'm aware of the ARIN IRR and how operators in the community
make use of it, and have run ISPs which have made use of the data
for route filtering.
> I appreciate that there is a process to go through for proposing ARIN
> policy changes, etc. Your suggestion that this be used when
> addressing an operational security matter is foolish and provides
> plenty of ammo for people who say ARIN is ineffective (or worse.)
Agreed; dropping me an email is a fine process for operational
security matters. Consider this one so reported.
President and CEO
More information about the NANOG