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

AP-WG,


I've included below an email which was sent to the authors of 2014-03 as a
followup to this email (dated Sat May 16 01:40:13 CEST 2015):

> https://www.ripe.net/ripe/mail/archives/address-policy-wg/2015-May/009982.html

Saku, Job and I discussed these ideas but the discussions didn't come to
anything.

The suggestions below don't fix everything with ASN assignment because 100%
solutions don't work.  However they provide a practical and workable
mechanism which trivially deals with the vast majority of cases, and
provides a known working mechanism for creating a run-out pool for ASN16,
all based on policy principals which are either in place for other
resources, or else which have been tried and tested in practice.

I'm planning to write this up as a formal policy proposal in the next short
while,  as an alternative to 2014-03.  If anyone has suggestions or tweaks,
please feel free to bring them up.

Nick


-------- Forwarded Message --------
Subject: Suggestions on a new asn assignment policy
Date: Sat, 16 May 2015 00:43:18 +0100
From: Nick Hilliard <nick at foobar.org>
To: Job Snijders <job at instituut.net>, Saku Ytti <saku at ytti.fi>
CC: AP WG Chairs <apwg-chairs at ripe.net>

Saku, Job, WG Chairs,

re: my email to ap-wg of a couple of moment ago, here are some ideas I've
been mulling over:

- if an end user wants a single ASN32 and they don't already have one, they
should get it on the basis of entitlement.

- if an end user wants more than one ASN32, they should get it on the basis
of a needs-based policy.

- if an end user wants one or more ASN16s, they should get it on the basis
of an needs-based policy, unless the remaining pool of ASN16s has reached a
certain threshold

- regardless of the requirement, end users may only receive one ASN16 from
the remaining pool, and this should be assigned on the basis of a
needs-based policy.

The needs criteria can be collated by both operator input and by taking a
look at historical assignment reasons: the ripe ncc have 25 years of
experience in assigning ASNs and have a large database of reasons that
end-users have put forward on their application forms.  But we already have
a pretty good idea of what this list should include.

Basing a new policy along the lines of these principals will provide the
following:

- no requirement for charging

- trivially deals with the most common case, namely assignment of a single
asn32

- a runout policy for asn16s which both has well-understood limitations and
will probably be palatable to the ripe community, as it's proposed on a
similar basis to the last /8 + will be subject to 24m rule.

- no practical way of asn32 resource exhaustion because each application
will be individually evaluated by an IPRA (either on the basis of 2007-01
for end-user authentication or else on the basis of needs evaluation once
that authentication has been completed).

- continuation of existing ASN16 policy until a hard limit is hit, after
which a run-out policy will apply

- conceptually very similar to ipv4 / ipv6 policy.

- hopefully an end to lies on asn application forms for asn32s

I don't know what you guys feel about these suggestions, but I think they
could be used to create something a good deal better than what we have
right now.  If you want to use these suggestions to form 2014-03 v3.0, you
are welcome to do so, but I would ask you kindly to acknowledge my input as
appropriate.

Alternatively, if either or both of you have got tired of 2014-03, I would
be happy to take up the baton and run with something along the lines of the
above.

Nick