On 13/01/2015 17:23, Elvis Daniel Velea wrote: > Regarding the current configuration, well.. it requires the requester of > the ASN to come up with a reason that can not be verified by the RIPE NCC > and with a predicted set of peers that may or not peer with the assigned ASN.
Elvis, you probably know the documentation much better than I do, but the formal requirement for multihoming has been in place since at least RIPE-140, dating from 1996. RIPE-140 refers to existing assignment practices and from what I remember of before that date, there was an informal expectation of multihoming for ASN assignment from the very early days of the Internet, even if it wasn't formally documented. As a community, we managed to arrive at a practical workaround, namely that you can apply for an ASN if you have a plan to multihome and can state a name for a potential peering partner. We all quietly acknowledge that it might not match the spirit of the policy, but it works and has worked for as long as the RIPE NCC has existed. It needs to work because often an organisation needs an ASN even when they're not yet ready to multihome. Again, let me be clear where I'm coming from: if we are going to change a policy which has been in existence for more than 19 years, let's change it to what we want for the next 19, rather than put in place a temporary stopgap with the aim of plugging a leak. If this means being patient for another couple of months until RIPE71, then that's fine by me. > Also, from your e-mail I understand that you are sure the AGM will vote > within 'a couple of months' to charge for ASNs. Do you know something that > I don't? :) Then you misread my email: I have no more information than anyone else about how people might vote. Nick
