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
