[address-policy-wg] 2014-03 "Remove Multihoming Requirement for AS Numbers Assignments" take #4

Hi,

On 11/08/15 13:44, Job Snijders wrote:
> On Tue, Aug 11, 2015 at 12:32:53PM +0200, Mikael Abrahamsson wrote:
>> On Tue, 11 Aug 2015, Job Snijders wrote:
>>> I've noted as an argument opposing this proposal: "An adversary could try
>>> to deplete the pool of available ASNs." If someone has a workable
>>> suggestion how to resolve that in policy, I am all ears, but I wouldn't
>>> mind a pragmatic approach where we just trust our community and deal with
>>> issues if and when they arise.
>> Cap the number of ASNs handed out until the policy is evaluated.
>>
>> RIPE is allowed to hand out $NUMBER ASNs under this policy, when $NUMBER/2
>> has been reached, please come back and tell us how it went.
>>
>> If $NUMBER is in the 10k-50k range, and we're talking 32bit ASNs, we haven't
>> used up a huge amount of this limited resource.
> Very interesting approach! We'd call it the "Anything goes" ASN pool.
> Arguably this approach mitigates the risk of depleting the entire pool.
I also like this approach.

I would even go further and say that only 32bit ASNs should be handed 
out using this approach.
16bit ASNs (the few hundred still remaining) should be handed out only 
based on multihoming/verification requirements while 32bit ASNs could be 
handed out upon request.

I believe that using a very small (*) cap may require us to re-visit 
this proposal in a short period of time. I propose to cap at 1/8 of the 
32bit ASN pool (~4 billion divided by # of RIRs and then divided by 8 = 
approx 100million) and re-visit the ASN policy once we have been 
notified by the RIPE NCC that we are 6-12 months into reaching this cap 
or when we notice that something has gone wrong and needs to be changed.

regards,
elvis

(*) as the ASN32 pool is over 4 billion, 50k out of 4billion is very small