On 4/30/2013 10:36 PM, Jimmy Hess wrote:
On 4/30/13, Owen DeLong <owen@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)