[address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)

Hi,

just a small reaction to what you have written (in line).

Dne středa 6. února 2019 10:39:24 CET, Daniel Karrenberg napsal(a):
> 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.

No problem here. I would be one of them, but I know that there won't be 
consensus.
> 
> 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)

I also agree with that.
> 
> 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.

Here it starts. I would say get such a LIR what you have got (to /22 of 
course). Even by means of multiple /24s. But not blocks smaller than /24, as 
it would be useless. Maybe let them decide if they would like to wait for 
whole /22 where there would be less then 4x /24 (in that one case).
> 
> 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.

No dispute here.
> 
> 1) Motivate the choice for /24 in terms of being the smallest block
> useful to route packets considering current routing practice.

Also no issue here. Motivate yes, require no. Keep /22 possibility so the 
complete runout of IPv4 won't be postponed.
> 
> 2) Explicitly mention the non-goals of the policy as discussed.

I think that those were discused here in the list. I don't think that it 
should be written in the policy itself.
> 
> 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"?

You cannot be sure where it would happen.
> 
> 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.

Sure, add there the waiting list if needed, but do not change the /22. This 
way it will be consistent.
> 
> 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.

I'm strongly agains that. Let's keep there explicitly /24 as the longest 
routable prefix. Allowing a longer one would give a signal to other RIRs that 
it is fine with us. That would bring yet another deagregation so more junk in 
routing tables. I'm not sure that we would all agree on changing our BGP 
filters to allow that. And if so, someone whom will be given such small pool 
would have problem with reachability.
> 
> 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?

If you keep there /22 and /24 as an option, than there would be no problem.
> 
> 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?

Then it would be wise to pass a policy that would say that. Like: "IPv4 is 
considered to be a legacy protocol. RIPE would not provide any allocation/
assignment of IPv4 resources." Or what ever.
> 
> 5) Maybe mention explicitly that one has to be a LIR in good standing to
> be on the waiting list.

More LIRs on the list means smaller chance that anyone would get an address 
pool. So let them wait there, it just as easely may work as a motivation 
torward IPv6. Like: "Just look at that list! IPv4 is gone for good."

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: </ripe/mail/archives/address-policy-wg/attachments/20190206/ac880d4b/attachment.sig>