[arin-ppml] Policy Proposal: IPv4 Recovery Fund

[Owen DeLong]

>
> 2) The allocation methodology specified/required by the language at  
> the end of
>   the section named "Distribution of Recovered Space" has a major,  
> if not
>   fatal, flaw.  To wit:
>
>     IF, for example, while nothing of a /21 or larger is available,  
> two ORGs
> 	   are each approved for a /21 on May 15, two more are approved (for
> 	   /21s) on June 1, AND an ORG is approved for a /20 on July 1,
>     THEN, when a /19 becomes available on July 15, under the 'best  
> prefix
> 	   match' rule, the "July 1" ORG would get a /20, and each "May 15"
> 	   ORG would get a /21, with the two "June 1" ORGs being left out.
>
>   I  believe that the 'desirable' outcome in that situation is that  
> all 4 of
>   the /21 requesters should get space, and that the /20 requester  
> should have
>   to wait for the -next- free block.
>
I actually thought about this, and, frankly, I think that the  
desirable outcome
is that the /20 requester gets in front of the two /21s.

The reason being that /21s are, by definition more likely to come up  
more
often. However, even in a situation where /20s  or /19s are more  
frequent,
the end result would be that the next /19 or /20 would most likely  
fill the
two /21s needs.  Since block fragmentation tends to be pretty much a
one-way process, I think minimizing block fragmentation in this way
is actually a desirable outcome.

Owen