On 25/12/2014 10:39, Job Snijders wrote: > So you are using a terrible amount of handwaving and overbreathing to > suggest that we refrain from ASN Assignment policy changes until the AGM > decides to start charging a yearly fee for ASNs again? > > What if such a yaerly fee is never introduced?
As a more general issue, we need to accept as a community that there is a crossover between RIPE Community policy and RIPE NCC membership policy, and that this is one of those intersections. The initial-idea to implementation-time for a RIPE policy proposal is rarely less than 12 months. Rather than thinking in terms of now or 6 or 12 months time, it's a better idea to formulate policy based on where the RIPE Community might want to be several years down the road. Based on this, the questions we need to ask *now* about what policy we want down the road should revolve around this: > What's absurd is that currently you cannot just get an ASN when you ask > for one. The current policy wording is a bit annoying but we're all used to the idea of providing the RIPE NCC with the correct incantation to get around its restrictions, so the net effect at the moment is that you can get an ASN if you want one. I.e. we're already running with a liberal assignment policy. All things considered, there's not a major problem living with the current policy formulation for another 12 months if that's what it takes to fix the policy properly. As a brief aside, we previously had this problem with fanciful story-telling to obtain IPv4 PI assignments. At the time the community agreed that telling porkie pies to justify assignments was probably neither clever nor compatible with good stewardship of resources. The way to fix this issue is to understand what the main underlying problems are with ASN assignment. They are: 1. no garbage collection 2. limited supply of ASN16s, causing exhaustion in the medium term The limited supply of ASN16s is only a problem because of lousy BGP Community support for ASN32s. If the IETF were to fix this problem, there would no substantial difference between 2-byte and 4-byte ASNs and we'd all be happy with a generic liberal assignment policy for all colours of ASN. In the interim, it's a question of interpretation as to whether it's worth changing the policy to slow down the run-out rate or not, given that the IETF is apparently more interested in the latest shiny baubles than fixing the BGP protocol to support this basic feature. The simplest way to implement garbage collection is to apply a small charge to each resource. The current iteration of this proposal suggests a partial garbage collection method which is IMO unworkable. It's unworkable because the RIPE NCC has never before had a policy of reclaiming resources because the initial application justification was changed, so going back on 20 years of working policy will probably be legally dubious in several of the jurisdictions that the RIPE NCC operates in. There's also a issue surrounding what level of change from the initial assignment criteria would be acceptable for reclaiming the resource. In other words, the proposal doesn't fix the problem of garbage collection; it simply shifts it to the lawyers. This is not clever. The only mechanism guaranteed to work as a garbage collection mechanism across all 76 or so jurisdictions is payment for receipt of good or services. Pretty much every legal system in the world accepts non payment of dues as a basis for breach of contract. Other than striving towards as being simple as possible (but no simpler), it's probably a good idea to align ASN assignment policy with other number resource policy. There's been no good reason suggested as to why ASN assignment policy should head towards more complicated rules when ipv4/ipv6 assignment/allocation policy has already gone in the opposite direction. Nick
