"It's the end of the world as we know it" -- REM

Wed May 1 07:51:08 UTC 2013

On 4/30/2013 10:36 PM, Jimmy Hess wrote:
> On 4/30/13, Owen DeLong <owen at delong.com> wrote:
>
>> With all due respect, this is a reference in section 8.3 to call out that
>> the policies in section 4 regarding qualification of recipients are to be
>> followed when determining eligibility for an 8.3 transfer.
> I don't read a reference to section 4 there.  don't think it's a
> reasonable belief, that a network operator supplicating for transfer
> of IPv4 resources,  would come to this conclusion -- there is no
> reason to select a specific section to apply because no section is
> mentioned,
> reading the policy on their own, and  what you are seeing there -- may
> be a result of
> bias from your prior exposure to another interpretation of the language.
>
> Its also possible, that all of us who were reviewing the proposed
> transfer policy language read some rationale statement at one time or
> another, and just (incorrectly) assumed that the final language
> accomplished our intended effect.
>
>
> I don't think this issue should effect any network operators at this
> time, but nonetheless i'm concerned about the RIR policy having
> confusing, surprising, or hidden ramifications built into it,  which
> are problematic and not previously considered.
>
>

I was the original policy modification author. The first version I 
submitted said:

"Add a subsection to Section 8 (Transfers) of the NRPM:

"Justified Need" for resources associated with a transfer shall be
determined using the "4.2.4 ISP Additional Requests" criteria applied as
though the recipient has been a subscriber member of ARIN for at least
one year (whether or not that is the case)."

Then In a followup email I pointed out:
"... Section 8.3 has NO language exempting itself from the 3 month rule. 
That's what I hear on the list, but I looked it up, and it isn't there. 
That's how I ended up writing this proposal, after all.

The only exemption is in 4.2.4.4. That exemption ONLY works if you are 
not getting an initial assignment through transfer (a likely scenario 
for new orgs post-runout) AND you are not a new member who only recently 
got their initial 3 month supply (where you'd be restricted to using 
transfer in 3-month increments for the first year in order to grow).

AND there's other bugs in that 4.2.2.1.1 and 4.2.2.1.3 and 4.2.2.2 (at 
the very least) call out specific block sizes that might be *smaller* 
than the block you're trying to qualify under transfer."

I then followed up to that with some specific scenarios...

"A. My hypothetical ISP provides service to a small town. I presently 
get two /24s of IPv4 space from my upstream provider and I'm using them 
at about 85%. ARIN has run completely out of addresses. A benefactor 
arrives and offers to transfer a /22 to me and pay for me to multihome.

I attempt to use 4.2.2.2 (Initial Allocation to ISPs, Multihomed) for my 
justification. I need to demonstrate that I am efficiently using the two 
/24s. Done. I comply with 4.2.2.2.1 (SWIP). I attempt to comply with 
4.2.2.2.2, but my growth shows that I won't really need more than a /23 
for about 7 months. Transfer would be denied because 4.2.2.2.2 has a 
three month rule (as I claimed above). Benefactor takes his space 
elsewhere, and I lose out.

B. My hypothetical ISP provides service to a single data center. I 
presently have a /20 that I was able to obtain from ARIN a few months 
ago, and I wasn't an ARIN subscriber member prior to this. I have the 
opportunity to acquire another ISP in town which has a /20 of its own, 
but which it isn't using very well because their growth plans failed 
after I opened up. I can demonstrate that my /20 and the second /20 from 
the acquisition would be filled within a year if I complete this 
transfer under section 8.2, but I'll only be able to fill out my 
existing /20 over the next three months. However, because I am under 
4.2.4.3 (Subscriber Members Less Than One Year) my 8.2 transfer is 
denied, again because 4.2.4.3 has a three month rule (as I claimed above).

on the flip side...

C. My hypothetical ISP provides service to a small city that is served 
by only one transit provider, so I cannot multihome. It has been using a 
/20 from the upstream ISP and is efficiently using 16 /24s worth of 
space with reassignment documentation (satisfying 4.2.2.1.1 and 
4.2.2.1.2). I provide detailed information showing that I can use a /20 
within the next three months (satisfying 4.2.2.1.3). Now that I have met 
all the tests, I complete a section 8.3 transfer for a /14 worth of 
space (because I have loads of money I won in the lottery). As far as I 
can tell, there's nothing in the NRPM that blocks that transfer... 
because I've met all the tests in 4.2.2.1. "

Then, after a bunch of comment and feedback (particularly around how 
end-users shouldn't be judged by the ISP criteria during a transfer), I 
created the simplified language:

"Add to Section 8.3 "...they can justify under current ARIN policies
showing how the addresses will be utilized within 12 months."

Remove from 4.2.4.4: "This reduction does not apply to resources
received via section 8.3. An organization receiving a transfer under
section 8.3 may continue to request up to a 12-month supply of IP
addresses."

The *intent* of the Section 8.3 language was that it mean "can justify 
(using current ARIN policy for testing what 'need' means) showing how 
the addresses will be utilized within 12 months" and *not* "can justify 
(including all of the various gotchas in Section 4 that apply to 
allocation operations)"

It was never my intent to, for instance, require the recipient of a 
specified transfer under 8.3 to be required to comply with 4.2.2.1.4 
"Renumber and return" for instance.

Now, the actual language that is in the NRPM says "The recipient must 
demonstrate the need for up to a 24-month supply* of IP address 
resources under current ARIN policies and sign an RSA." ... if someone 
thinks that "demonstrate the need...under current ARIN policies" means 
not just "demonstrate the need" but also "fall into compliance with 
every nuance of section 4 that might be applied if they were getting the 
addresses from ARIN" (ex. 4.2.1.5 requiring a /20 minimum for ISPs) then 
I guess we need another policy modification.

Is that really how ARIN staff is interpreting it?

And why is this discussion here and not on arin-ppml?

Matthew Kaufman

(* note that it is 24 months because I submitted another policy proposal 
that was considered at the same time to bump the 12 months up to 24, and 
both passed)