[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
"It's the end of the world as we know it" -- REM
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
> 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
"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 22.214.171.124. 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 126.96.36.199.1 and 188.8.131.52.3 and 184.108.40.206 (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 220.127.116.11 (Initial Allocation to ISPs, Multihomed) for my
justification. I need to demonstrate that I am efficiently using the two
/24s. Done. I comply with 18.104.22.168.1 (SWIP). I attempt to comply with
22.214.171.124.2, but my growth shows that I won't really need more than a /23
for about 7 months. Transfer would be denied because 126.96.36.199.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
188.8.131.52 (Subscriber Members Less Than One Year) my 8.2 transfer is
denied, again because 184.108.40.206 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 220.127.116.11.1 and
18.104.22.168.2). I provide detailed information showing that I can use a /20
within the next three months (satisfying 22.214.171.124.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 126.96.36.199. "
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 188.8.131.52: "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
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
It was never my intent to, for instance, require the recipient of a
specified transfer under 8.3 to be required to comply with 184.108.40.206.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. 220.127.116.11 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?
(* 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