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

Alex Le Heux wrote:

Dear Wilfried,

...

...

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?

When deciding on the size of the temporary assignment pool, we did indeed look at the number of concurrent outstanding assignments in the prior years.

The maximum amount of space that has been assigned concurrently since the temporary assignment policy has been implemented is as follows:

- 2x /20 - 1x /22 - 1x /24

total: /19, /22, /24

The temporary assignment pool has not been heavily used yet in 2012. Part of the reason for this is probably that some of the events that traditionally require large temporary assignments (~ /16) happen only at the end of the year or in odd-numbered years.

I hope this answers your questions,

Indeed, thank you very much! Wilfried

if you have any others, please do not hesitate to ask.

Best regards,

Alex Le Heux Policy Implementation Co-ordinator

On 17 Sep 2012, at 17:59, Martin Millnert wrote:

Why can't conferences run NAT-something+IPv6 like the rest of everything?

Let's avoid this rat-hole. The issue is whether there should be temporary assignments or not. Whatever the justifications are for (not) having these or other approaches to solving those issues simply don't matter. The question here is simple and needs no refinement or qualifications. They just complicate matters and don't help. Should there be temporary assignments? Yes or no. My personal preference is to burn through all the remaining IPv4 space as quickly as possible in the (probably forlorn) hope that it puts an end to these angels on pinhead debates. :-)

* marcin@leon.pl (Marcin Kuczera) [Tue 18 Sep 2012, 00:05 CEST]:

On 2012-09-17 18:59, Martin Millnert wrote:

...

[Devils advocate] Why must there be special treatment for conference-space (temporary assignments) at all? Why can't conferences run NAT-something+IPv6 like the rest of everything? Since networky-conferences are the most common requesters of these temp-blocks in the first place by my understanding, wouldn't that be an excellent place to start adapting to the future rather than getting special treatment and sticking to the old?

Couldn't this help with dissipating clue to real networks, etc?

Just a thought.

Clear point of view, I like it !

I don't think the point of the policy is to punish people for having addressing needs. -- Niels.