[arin-ppml] Fee structures for ARIN

[Jeff Wheeler]

On Sat, Oct 29, 2011 at 1:51 PM, John Curran <jcurran at arin.net> wrote:
> Could other folks interested in ARIN improving its IRR services
> (or not investing here) please speak up?   At the recent ARIN
> meeting, we heard advocates of those who want ARIN to do more
> with IRR, but also from those who believe that there's already
> an abundance of routing registries out there and ARIN investing
> time and effort in this area makes little sense.  More input
> from the community on this topic would certainly be helpful.

Many folks in the ARIN region do not understand how to take advantage
of IRR, or why it is of particular benefit for the RIR to operate a
good IRR database.  You have to look at RIPE's IRR, and then compare
to the data quality in ARIN-region IRRs, to understand what's really
going on.

All the major north american IRR databases are full of out-dated proxy
records which should have been deleted but haven't been, data for
previous holders of now-defunct ASNs, and so on.  This is not the
fault of the databases, but of the users.  The operators of RADB and
friends don't have any way to authenticate users against ARIN POCs.

Earlier this year, John discussed some ideas to greatly improve the
ARIN IRR service, which would make it more user-friendly.  If this
were done, it could go a long way toward enabling ISPs to correctly
filter eBGP sessions without implementing RPKI (which has far higher
cost and risk.)  It could reduce news-making BGP leaks that wreak
havoc without router vendors having to write any new code, without a
complex certificate system, and without the political concerns that
many people have about RPKI.

It could also be a tool to combat DFZ growth, not through making rules
or telling any address-holder that they can't inject their routes into
the DFZ, but through simply preventing mistakes from propagating
outside their own AS.

On Sat, Oct 29, 2011 at 5:33 PM, Jimmy Hess <mysidia at gmail.com> wrote:
> That is, I would see the technical characteristics of all the IRRs
> being standardized,

This is already the case.  Part of the problem is actually that IRR
databases have too much functionality which makes it more difficult
than necessary to implement (if you decide to roll your own software.)
 A subset of the defined features, which ignores RPSL, is perfectly
fine.

The trouble here is RPSL was meant to allow operators to fully express
any routing policy they might wish to configure into their network in
an abstract, vendor-neutral form, so all your route-maps or
policy-statements, ACLs / firewall filters, etc. could come from your
RPSL database, which you may choose to operate privately within your
organization, or store in a public database.  That is not needed to
simply prevent operator errors from wrecking the DFZ.

If you ignore all that extra crap, and implement only what is needed,
it is extremely easy to have a light-weight set of IRR tools.  I am
guessing this is what you mean should be standardized, and I
completely agree with you.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator  /  Innovative Network Concepts