ARIN / RIR Pragmatism (WAS: Re: RADB)

Sat Oct 25 15:07:35 UTC 2014

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