[arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8

[David Huberman]

Hi Scott,

Thank you for the reply. Please allow me to explain why I keep
repeating that ARIN is not a regulator. I believe ARIN only 
exists to serve the network operator community. It has been 
tasked to do so via the IETF.

You wrote:
"It doesn't blindly register any request it receives".

I agree. But let's discuss those rules.

For ASNs, there exists a minimal rule set that only seeks to ensure
that a requestor has a legitimate need PER RFC1930.  Again: the
rule set - the policies in NRPM - are wholly about RFC1930 
compliance.  In turn, RFC1930 is a concise document which lays
out the differences between locally-unique and globally-unique
autonomous systems.

For IPv4, there exists a rather expansive rule set.  But when NRPM
was first published in 2003 - based primarily on the rules found
in various spots on the ARIN website that Kim Hubbard maintained
prior to that - the rule set was designed to ensure that the requestor
met the terms of RFC2050. 

RFC2050 was an important document at the time it was published,
because literally, routers were melting.  BGP could not converge due
to disaggregation.  So RFC2050 addressed that problem -- and the
longer-term problem of IPv4 exhaustion without a safety net -- by
writing some rules about how to more sanely give out IP address
space. 

Today, however, RFC2050 has been deprecated by RFC7020.  RFC7020
lays out three primary goals:
- Allocation Pool Management
- Hierarchical Allocation
- Registry Accuracy

With an exhausted IPv4 pool, there are no "pool limitations at the time
of allocation" as there are no allocations.  ARIN's role in IPv4 is primarily
the third goal above: registry accuracy.

That's why I advocate removing needs-basis from transfers in a post-
exhaustion world.  There's no pool to manage[1], so the only OFFICIAL
mandate ARIN has from the network operator community is to run an
accurate registry.


My whole point is that the network operator community governs itself.
We make technical rules -- protocols -- collaboratively in the IETF. In
turn, we as a community have tasked ARIN with managing the numbers
part of the network, and have done so with formal documents that have
clear directives.

When this community -- the ARIN policy making community -- makes
rules (and takes on an attitude) that is beyond the mandate of the
governing RFCs, that's when you get the Randy Bush's rightly
decrying the "amateur policy makers". That's when you get companies
like Depository trying to literally compete with ARIN. And that's when 
you get network operators who are less and less interested - and 
in some cases, actually dis-motivated - from participating in the ARIN
system.

I advocate the principles of RFC7020, and in doing so, beg this community
to only make rules which conform to the spirit of IETF drafts. I beg the
ARIN CEO and Board to find a way to run a registry operation that is
nimble and responsive. The better ARIN is - policy-wise and operationally
- the better ARIN serves us.

/david

[1] Yes, I know. There are bits and pieces that come into ARIN's inventory
due to churn (companies going out of business for real and defaulting
on the Terms and Conditions of the RSA, and therefore forfeiting their
allocations and assignments).  That's why I haven't touched section 4,
except an attempt prior to ARIN in Phoenix to simplify the section.


________________________________________
From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on behalf of Morizot Timothy S <Timothy.S.Morizot at irs.gov>
Sent: Friday, April 4, 2014 7:45 AM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of David Huberman
> Sent: Friday, April 04, 2014 9:31 AM
>
> ARIN is a registry, not a regulator.

You keep saying that, but simply asserting it does not make it reality. ARIN doesn't just register number allocations, it also makes those allocations. It doesn't just blindly register any and every request it receives. Everyone agrees to some form of needs basis when it comes to the free pool. (At the extreme end, everyone agrees it would be unreasonable to allocate the entire free pool, v4 or v6, simply because somebody asked for it.) They also have to ensure that bad actors don't hijack number allocations that are rightfully assigned to others. All of that requires rules (regulations by another name) and enforcing those rules makes ARIN the regulator of them.

You can disagree with the scope and nature of the regulations or with the actions of the regulator to enforce them, but the assertion that ARIN is not a regulator is simply false and will always be false as long as there are any rules at all in place that must be enforced.

Scott
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.