[address-policy-wg] Fwd: Suggestions on a new asn assignment policy

David,

thanks for your comments.

On 11/08/2015 12:41, David Huberman wrote:
> Respectfully, I think the WG is trying to solve a problem which doesn't
> exist.

the policy has one problem now and is facing ASN16 depletion in the future.

The problem now is that you can only get an ASN if you are "multihomed" and
there are a bunch of situations where this is causing unnecessary problems.
 People work around this by lying on the application form and this is not
good stewardship of number resources.

Regarding depletion, we have an option of viewing this as a problem, or
not.  I view it as a problem because BGP community support for ASN32 is
very poor, and future entrants to the IP market will be penalised for being
future entrants.

There are substantial regulatory problem associated with existing market
players effectively locking out future players, and given that the RIPE NCC
has a monopoly in ip number resource assignments in this part of the world,
this is an issue which would be best avoided if possible.

> And I STRONGLY dislike policy discussions and text which penalize
> 99.9% of the people just trying to operate a network because of the 0.1%
> of idiots who might think it's fun to do something stupid.

The suggestion provides for an ASN32 on demand to anyone who wants one
without any justification.  If you look at the numbers, this means that
about 85% of ASN assignments can be automated fully.  This is a serious win
in terms of registry efficiency which directly benefits those 85% of
assignments.

The remaining 15% will have more relaxed policies in place after their
first ASN assignment until the ASN16 pool has reached a certain point.

Future market entrants will benefit by being given a toe-hold in the door,
in the same way that future market entrants are given a toe-hold in the
door with the last /8 ipv4 allocation policy.  I.e. we already have a
precedent for community support for this.

> I believe ASNs should be given out to LIRs in an on-demand basis without
> cost and in an automated fashion.

At current run-rates, there are a 3-4 years of ASN16s left.  This wouldn't
be a problem if ASN32s were semantically identical to ASN16s, but
unfortunately they are not.  As has been pointed out repeatedly, there is a
root cause problem here which is not being addressed by the IETF and
if/when it's addressed, it will take may years to roll out - far longer
than 3-4 years.

> If at some point in the future, the NCC or community discovers some
> child has abused the system and taken an absurd number of ASNs, the NCC
> has the power to revoke the ASNs under sections 6.3, 9.3, and 9.4 of the
> RIPE NCC Standard Service Agreement.

As Mikael Abrahamsson points out, this is extremely difficult to implement
in practice.

Nick