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 <[email protected]> To: Job Snijders <[email protected]>, Saku Ytti <[email protected]> CC: AP WG Chairs <[email protected]> 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
