On Jan 9, 2011, at 6:30 PM, Jeff Wheeler wrote: > > John, > > 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."
Jeff - 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. /John John Curran President and CEO ARIN