[address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments)

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