[rpd] SL-BIS (Was Re: Appeal Committee Terms of Reference (Version 1))

[Owen DeLong]

> On Aug 17, 2017, at 20:45 , David Hilario <d.hilario at laruscloudservice.net> wrote:
> 
> Hi,
> 
> 
> On 17 August 2017 at 19:35, ALAIN AINA <aalain at trstech.net> wrote:
> 
>> The spirit of the current SL which SL-bis followed is to make fair
>> distribution, give chance to many, at all stages, but avoid stocking unused
>> space.
>> 
>> Thus, the no limit on numbers of request from members in Phase 1 and Phase
>> 2.
>> 
> 
> That part bugs me in the current version and I oppose any new version
> of the policy keeping it in.
> How do you see this being done in practice?
> 
> Either have a limit or not have one at at all.
> If you have a need, the evaluation process from AFRINIC will result in
> a number that you need for your network.
> 
> If they concluded you needed a /18, but can only issue a /22 per request.
> A large LIR will still be above 90% utilisation even after receiving
> their /22, there will literally be nothing to review by AFRINIC staff
> in any subsequent requests that all can be sent at the same time
> anyways,

Actually, no… They shouldn’t be allowed to be submitted simultaneously.

An organization should only be allowed one in-process request at a time and should not
be allowed to submit a subsequent request until they have received a final result to their
previous request.

In this way, you can get to the front of the line needing a /18, but you get your /22
and other organizations also in line get their /22 before you get a second helping of /22.

This seems like rational policy to drive fairness in my opinion.

Telling the organization that they can’t get in line for seconds for some time period in order
to support speculative future organizations that don’t exist yet getting in line in front of them,
on the other hand, doesn’t make any sense at all to me.

> 
>> From a logistic point of view it really doesn't make much sense to
> keep these limits in there.
> 
> We can set a hard limit max X amount once per LIR.
> Or once every X amount of months/years limit.
> Or have no limits.
> 
> All of the three above have pros and cons, but at least they are clear.

Why isn’t it clear to set a hard limit of X amount per request and require that you go
to the back of the line behind all other current requests for any subsequent request once
you get your X amount?

> But have max amount of IPs per request with no limits on amount of
> request is just asking for AFRINIC to get flooded by requests, creates
> confusion and ultimately large fragmentation at a rapid rate.

If there isn’t a requirement for serialization of requests, then you are correct, but there
should be a requirement for serialization of the requests such that you don’t get back in line
for request number 2 until request number 1 has been completed, so anyone that filed a request
between your first request submission and your first request completion will be in front of you
in the line.

Owen