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

Fri Apr 4 13:25:43 EDT 2014

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: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman
Sent: Friday, April 04, 2014 11:22 AM
To: Morizot Timothy S; arin-ppml at arin.net
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: 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.
_______________________________________________
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.