David is right that when he advocates removing needs-basis from transfers in a
post- exhaustion world. However, the only difference between then and now is
that ARIN probably has a larger unallocated IPv4 then it will after Exhaustion.
The size of what ARIN has in its unallocated pool really makes no difference
to ARINs Mission, and the Mission won't really change at Exhaustion.
I have said many times in the past that ARINs Mission is TO Allocate and it
isn't NOT TO Allocate which some of the IPv4 polices are designed to do. Of
course after I pointed that out many times and many ways, the ARIN Board took
it upon itself to remove that phrase from its Mission Statement - without input
from this Community I might add. (But it still exists in related documents.)
ARIN should not be in the business of turning down resource requests if they
have the resources to allocate - EVER. Doing so is arbitrary and
discriminatory. ARIN should only be in the business of right sizing
allocations to match the size of the organization (including their existing
network size) making the request - AND - keeping the registry database as
accurate as possible.
When ARIN denies allocation requests like they did to us, they force
organizations like ours to make a decision on possibly purchasing resources
outside of ARIN. When that happens, the result of the needs based polices may
be an off the ARIN books transaction and the registry database becomes less
accurate. Thus existing policies cause ARIN to NOT be able to fulfill its
Mission of keeping an accurate database.
But there I go again, trying to infuse reality and common sense into policy
discussions . . . . .
Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA 30338
770.656.1460 - Cell
770.399.9099- Office
℠ Eclipse Networks, Inc.
Conquering Complex Networks℠
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of David Huberman
Sent: Friday, April 04, 2014 11:22 AM
To: Morizot Timothy S; [email protected]
Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
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: [email protected] <[email protected]> on behalf of
Morizot Timothy S <[email protected]>
Sent: Friday, April 4, 2014 7:45 AM
To: [email protected]
Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> 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 ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public
Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
