After reading and thinking I arrive at the following principles:
a) It is not tenable for the RIPE NCC to stop allocating IPv4 addresses as long as it has blocks that are useful to route packets. Note: As an individual I would very much like to just stop with this silliness. However I do not think this is tenable for us as a community. b) Once the pool decreases below that threshold the RIPE NCC has to maintain a waiting list in order to establish a sequence in case space becomes availble. Reason: see (a) c) It is not tenable for the RIPE NCC to require the first LIR on the waiting list to wait for more address space than a minimal usfeful block to accumulate. d) The length of the waiting list and other practicalities should be secondary considerations after these principles above. For instance, the RIPE NCC can always recover the costs incurred by the process from those using it. The policy captures these principles. The policy can be improved in a number of ways. Here are some considerations for the proposers in case they would wish to revise it: 1) Motivate the choice for /24 in terms of being the smallest block useful to route packets considering current routing practice. 2) Explicitly mention the non-goals of the policy as discussed. 3) Keep in mind our good experience with using concrete dates for policy changes. Consider to make the change on a specific date. This is more predictable than an event sometime in the future. "Run Out Fairly" worked pretty well. Specifically why not just say "This polixy into effect on September 1st 2019"? 4) The policy could be made more adaptable to future scenarios. This would prevent more ad-hoc policy changes which are a pain and do not look very professional to the world outside RIPE. Maybe the policy could be 'parameterised' so that the community can decide to change parameters rather than re-write the policy text. 4a) Consider the possibility that future routing practice may change the longest useful routing prefix away from a /24 as Randy alluded to. This should be a parameter. 4b) Consider the possibility, however unlikely, that the RIPE NCC receives a significant amount of address space to re-distribute. Would this policy still be supported by the community in this event? Should the allocation size be a parameter that can increase above the <smallest usable prefix> either by community choice or automatically if a certain pool size is exceeded? 4c) What happens down the road when IPv4 really becomes legacy? Can we make the policy applicable even then? Would (4) and (5) above do the trick? 5) Maybe mention explicitly that one has to be a LIR in good standing to be on the waiting list. Daniel
