niels=apwg@bakker.net wrote:
* nick@inex.ie (Nick Hilliard) [Sun 16 Sep 2012, 21:10 CEST]: [..]
There are a couple of options for dealing with this:
1. specify new time limits (e.g. receive one month in advance, hand back one week after)
I understand that the choice for a /13 to set aside for this was based on the ability to fulfill all temporary IP address space requests. Extending the time period would make this cramped, I presume.
Well, if I am not mistaken, this has been in effect for a while already. Thus, may I ask the IPRAs to give us some real numbers (max# of concurrently active assignments, minimum/average/max size of blocks assigned) and any other feeback that may be helpful? In general, I am in favour of #1, because it makes it easy for both sides to work in this framework, without bickering, finger-pointing and inventing good arguments. If it turns out, that there *is* competition in the future, we can *then* implement remedies. I would count on the NCC to give an early heads-up :-)
2. don't specify time limits but allow the IPRAs to have discretion on what seems sensible to them
This sounds good on paper but will in practice just lead to requestors going "But you gave them <points at otherconf> a month, why me only a week?!" which is good for neither IPRAs nor applicants. In effect it'll end up being just like a less overt #1.
3. keep the current time limits but ask the RIPE NCC whether it would be possible to implement a booking system. I.e. your assignment would only be active during the requested time period, but you would know well in advance what the options were.
This isn't a good choice either but may be the least-bad of all three.
I strongly dislike that option, it just complicates things and adds a "simple" mechanism to make mistakes and to have announcements leaking.
Having the ASN available earlier would help somewhat with ensuring routability as IRRdb's can be updated; having the IP blocks known will help too, even if they're not yet assigned.
Whatever we end up with, the ASN boundaries should at least be aligned with the address assignment period, probably even more generous. Given that ASN32 is there, there shouldn't be a shortage in the next few years :-)
If anyone has opinions on which of these they prefer (or any other suggestions on how to deal with the issue), can you either post here or let me know off-list and I'll summarise at RIPE65 in advance of posting a policy amendment for ripe-526 shortly after the meeting?
Lengthening the lease time for temporary ASNs separately from IP number resources should be an option.
A hobby gives me a vested interest in #1 so rather foolishly I hope more space can be made available to satisfy community needs, but it would already help to have the ASN and know other numbers earlier.
Whether we need this policy or not is a different aspect. And I am waiting for the club to hit some head/s for trying to see a bigger picture, like it was happening to me a short while ago on a different topic ;-)
-- Niels.
Wilfried