[arin-ppml] Policy Proposal 124: Clarification of Section 4.2.4.4

[David Farmer]

On 12/2/10 13:02 CST, ARIN wrote:
...
> Policy Proposal 124: Clarification of Section 4.2.4.4
>
> Proposal Originator: Martin Hannigan and Chris Grundemann
>
> Proposal Version: 1.0
>
> Date: 2 December 2010
>
> Proposal type: Modify, complete replacement of 4.2.4.4
>
> Policy term: Permanent
>
> Policy statement:
>
> 4.2.4.4. Subscriber Members After One Year
>
> After an organization has been a subscriber member of ARIN for one year,
> that organization may choose to request up to a 12 month supply of IP
> addresses.
>
> On the date that ARIN receives its last /8 as a result of the IANA
> executing section 10.4.2.2 of the NRPM and in accordance with the Global
> Policy for the Allocation of the Remaining IPv4 Address Space, the
> length of supply that any organization may request from ARIN from that
> moment forward will be reduced to three months. Any pending request
> submitted prior to that moment will continue to be eligible for a twelve
> month supply of addresses as long as need is established within thirty
> days of that moment.
>
> Rationale:
>
> ARIN's pending operational practice is that if an organization has a
> request in the ARIN hostmaster queue for IPv4 resources when the IANA
> declares the exhaustion phase (10.4.2.2), their request will be
> automatically truncated from a twelve month supply to a three month
> supply since policy in effect at the time of exhaustion will apply. 8.3
> and 4.2.4.4 are currently "in effect".
>
> Example: If an entity is asking for 4 x /24 for a 12 month period and
> IANA exhaustion occurs, a requester will receive, if justified, 1 x /24.
> If an entity is asking for 120 x /24 at the time that exhaustion occurs,
> they would only receive 30 x /24 if justified. If ARIN determines that
> this same entity would only qualify for 90 of the 120 x /24 requested,
> then that entity would only receive 22 x /24.
>
> ARIN has the equivalent of almost a /8 in at least one reserve, has
> recently received 2 /8's, received ~391 x /16's as a result of the
> distribution of "various registries" from the IANA and is guaranteed to
> receive at least one additional /8 (aggregate of about 92 million
> individual IPv4 addresses) as a result of the execution of 10.4.2.2 by
> the IANA. Considering the size of the supply, it would seem prudent to
> provide for all members needs in a fair and consistent manner as long as
> possible in order to support the continued orderly transition of the
> Internet to IPv6.
>
> The ARIN AC should review and determine what action if any should be
> taken at their next available opportunity, or sooner if they deem
> warranted.

Was the the third paragraph of the current policy intentionally remove? 
  That paragraph was intended to allow transfers via section 8.3 to 
continue to receive a 12 month supply and not restricted to 3 month like 
allocations from the ARIN pool. I believe it is important to retain this.

Since I did not see this change explicitly addressed in the Rationale, 
I'll assume that it was not intentional.  If that is incorrect, would 
you please explain why you think it is a good idea to restrict these 
transfers to a 3 month supply, and that should be more prominent in the 
rationale.

Also, I don't believe this policy effects the minimum allocation size, 
so I think there are issues with the first example you provide in the 
rational.  I'm not exactly sure how it would be applied for your 
examples, but the minimum allocation size is /20 (16 X /24) and 
therefore you would get a /20 as a minimum allocation, or possibly a /22 
for multihomed allocations.

I went back and reviewed the record for 2009-8 which is the Draft Policy 
that put the current language in place.  I don't see where anyone 
brought up the issue of how those currently in queue at the time of 
triggering event should be handled.  I will note that the original Draft 
Policy had this ratcheting down over time, while fundamentally the same 
issue existed, the multiple steps down would have lessened the impact of 
this issue.  So, thank you for bringing up this issue, while it was 
never directly discussed, I don't think it was ever anyone's intent to 
impact those in queue, only new requests.

Given that there was never any direction to the contrary in the 
Rationale or the Policy itself, I believe staff's plan for implementing 
seems consistent with the way other policies are implemented.  However, 
I wonder if this could be accomplished without actually changing the 
policy and simply by have the AC request the implementation of 2009-8 be 
accomplished by applying the triggered change in policy only to new 
requests when the triggering event occurs.  I don't think this is 
inconsistent with the policy as currently written.  This is an 
implementation detail, an important one I'll grant you, but I'm not sure 
it needs to be escalated to the policy itself.  Furthermore, if such a 
suggestion would have been Included in the Rational of the original 
2009-8 I believe Staff would have implemented the policy as desired.

So I guess I have a question for John Curran;  Would it be in order and 
sufficient for the AC to recommend to the Board that policy 2009-8 now 
section 4.2.4.4 of the NRPM have the triggering clause be implemented 
for new requests that are received after the triggering event, and that 
requests received before the trigger be grandfathered?

If that is possible, then we wouldn't need new policy and wouldn't need 
to implement the emergency PDP in this case.  It would simply require 
timely action, within the normal scope of activity, by the AC, the 
Board, and Staff, which I think is still possible at this point.

I'm not opposed to this policy, but I don't believe it is necessary to 
change the policy in order to achieve the desired result, assuming the 
only desired result is to grandfather those in queue with the 12 month 
supply.  Do others on PPML support this interpretation of section 
4.2.4.4?  Is this a reasonable course of action?

Thanks.

-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================