On 2014-10-25 08:25, John Curran wrote:
With respect to IRR support, the same answer applies. If the community is clear on direction, ARIN can strengthen the current IRR offerings, phase them out and redirect folks to existing solutions, or any other direction as desired. The hardest part is getting a common view in the community on the desired approach; this leads to the strong adoption that is necessary for these types of systems to have meaningful benefit.
I didn't necessarily intend to fault ARIN here, some very vocal folks have pushed ARIN (and others) pretty hard on focusing considerable resources on experimental systems (RPKI [/BGPSEC]) that may never see broad-scale adoption and use, for an array of technical, business, and geopolitical reasons. I could be wrong. As an ARIN and community member, I'd prefer to see more work on nearer term solutions and better leveraging existing systems that we're already captive to and will still need in the future (e.g., IRR hygiene work and more security rails, tool sets, training for operators, perhaps in-addr.arpa or other techniques to validate resource holders, etc..). If orthodox visions materialize that provide utility and a reasonable ROI without introducing excess risk and overhead and complexity and undue external dependencies for the folks that would be captive to those new systems, then great. I continue to believe that the only way any resource certification system is going to realize adoption is by taking this incremental approach of fortifying existing systems and supplying sufficient operational buffers, and that the easiest way to stunt deployment and adoption of RPKI is to slam it directly into the routing system and compromise current autonomy in routing operations that exists and makes the Internet resilient. Thanks for that response, John. -danny