Hi, On Wed, Dec 24, 2014 at 04:18:04PM +0000, Nick Hilliard wrote:

April 1 is three months away; otherwise, an excellent parody.

So do I take that as support of the policy, or opposition? And if the latter, what are you unhappy about which couldn't be brought up in the previous round already (since this new version really tries to incorporate all feedback that has been given)? Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

On 24/12/2014 18:14, Gert Doering wrote:

So do I take that as support of the policy, or opposition? And if the latter, what are you unhappy about which couldn't be brought up in the previous round already (since this new version really tries to incorporate all feedback that has been given)?

It's the evening of dec 24 so I'm not going to go into a whole rigmarole about the theory of bureaucratic policy. But as a general rule, most ripe community addressing policy over the last couple of years has been veering towards relaxation and simplification of rules rather than making them more complicated. This is particularly the case with ipv4, and almost the same with ipv6 from most practical viewpoints. As a community, we're pretty much together that this is a good thing. Then this proposal happens. It invents a magic number - one thousand. Yes, I'm aware of the distant practical basis for this, but let's not pretend that in every other respect the number isn't pulled straight out of the air because it happens to be an ordinal power of the number of fingers on most peoples' hands. Magical, nay divine, power is assigned to this number: thus far shalt thou abuse and no further! It creates a policy requirement to invoke RPSL, possibly one of the most inscrutably ill-defined languages ever devised, but the requirement is so poorly defined that anything could be credibly hurled into the database. E.g. "from AS23456 import AS-NULL". It creates a requirement to state a need for the ASN which the RIPE NCC will forbidden from evaluating. It also creates a requirement for the RIPE NCC to police this need. Not evaluate, mind you - just police it without evaluation. I'm trying to understand how this could possibly work, so in the unlikely event that there are no further emails from this address, you can assume that my brain has imploded due to a neural singularity. It conveniently ignores the awkward reality that in the event that an organisation might ever want 1001 ASNs, they could spend 10 euros registering a second company and continuing on their merry way. Guys and gals, I have shocking news for you: if someone is dishonest enough to abuse the rules using one organisation, they can just as easily abuse the rules with two different organisations and perpetrate twice as much abuse. Application of iteration theory indicates that this abuse may even scale linearly. The sensible approach to this is to relax the policy requirements for asn assignment - in exactly the same way that the ripe community has relaxed the policy requirements for other number resources - and then apply a small fee to help prevent egregious abuse. Note: not stop, because it is not possible to completely people abusing arbitrary rulesets without harming the common good. This is far simpler, most manageable, smaller, more internally consistent and generally more beneficial for the community than proposing byzantine policy. Look I'm sorry, but this policy draft is absurd and flies in the face of reality, common sense and practical application. Please kill it with fire. Nick

Hi, On Wed, Dec 24, 2014 at 05:02:20PM -0500, Randy Bush wrote:

...

Look I'm sorry, but this policy draft is absurd and flies in the face of reality, common sense and practical application. Please kill it with fire.

thank you

and if you can't figure it out, gert, i agree with nick, but am far less loquacious.

Nick, Randy, thanks - *that* message was very clear. (And I can see the point. The proposal is trying to work around the mishap that the charging scheme removed the fee for AS numbers, which we as APWG cannot directly decide - but of course the message has been sent at the last AGM and I'm fairly sure it has been heard. No idea what will happen on that front, though...) regards, Gert Doering -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Hey, You seem to give critic on many aspects, but offer solution to one aspect. You believe the magic 1k should be replaced by small fee. Well, that is what the 1k does, it gives non-zero fee to ASN, so that you dont want to request 32b of them. Same functionality without changes to billing procedure. The requirement for reason to request is for those who come after us, so that they will have data to work with. Why are ASNs needed? Does this seem problematic or wrong? I'm ambivalent on the RPSL aspect. How should it be remedied? Removed? Thanks, -- ++ytti

On 24 Dec 2014, at 23:18, Nick Hilliard <nick@inex.ie> wrote:

...

On 24/12/2014 18:14, Gert Doering wrote: So do I take that as support of the policy, or opposition? And if the latter, what are you unhappy about which couldn't be brought up in the previous round already (since this new version really tries to incorporate all feedback that has been given)?

It's the evening of dec 24 so I'm not going to go into a whole rigmarole about the theory of bureaucratic policy. But as a general rule, most ripe community addressing policy over the last couple of years has been veering towards relaxation and simplification of rules rather than making them more complicated. This is particularly the case with ipv4, and almost the same with ipv6 from most practical viewpoints. As a community, we're pretty much together that this is a good thing.

Then this proposal happens.

It invents a magic number - one thousand. Yes, I'm aware of the distant practical basis for this, but let's not pretend that in every other respect the number isn't pulled straight out of the air because it happens to be an ordinal power of the number of fingers on most peoples' hands. Magical, nay divine, power is assigned to this number: thus far shalt thou abuse and no further!

It creates a policy requirement to invoke RPSL, possibly one of the most inscrutably ill-defined languages ever devised, but the requirement is so poorly defined that anything could be credibly hurled into the database. E.g. "from AS23456 import AS-NULL".

It creates a requirement to state a need for the ASN which the RIPE NCC will forbidden from evaluating.

It also creates a requirement for the RIPE NCC to police this need. Not evaluate, mind you - just police it without evaluation. I'm trying to understand how this could possibly work, so in the unlikely event that there are no further emails from this address, you can assume that my brain has imploded due to a neural singularity.

It conveniently ignores the awkward reality that in the event that an organisation might ever want 1001 ASNs, they could spend 10 euros registering a second company and continuing on their merry way. Guys and gals, I have shocking news for you: if someone is dishonest enough to abuse the rules using one organisation, they can just as easily abuse the rules with two different organisations and perpetrate twice as much abuse. Application of iteration theory indicates that this abuse may even scale linearly.

The sensible approach to this is to relax the policy requirements for asn assignment - in exactly the same way that the ripe community has relaxed the policy requirements for other number resources - and then apply a small fee to help prevent egregious abuse. Note: not stop, because it is not possible to completely people abusing arbitrary rulesets without harming the common good.

This is far simpler, most manageable, smaller, more internally consistent and generally more beneficial for the community than proposing byzantine policy.

Look I'm sorry, but this policy draft is absurd and flies in the face of reality, common sense and practical application. Please kill it with fire.

Nick

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

Hi Gert,

So your suggestion would be to stall this proposal until we know what comes out of the next AGM, and then see if we need the clause in question at all, anymore?

I would not recommend stalling the proposal based on what will be decided. My strong suggestion would be to move forward regardless. The current policy text provides a fix for possible abuse of requesting AS numbers. And if there will be a charge in the future for an AS number via the charging scheme, that number would be easy removed to replace it by the charge for the AS.

What if the AGM decides to bring back a yearly recurring charge for ASNs, we loosen up our policy, the AGM decides to remove the charge once again, and Nick No Hats decides to send in 4 billion ASN requests to the NCC (I recall that it was you initially who was worried about the potential for abuse here, so I'm slightly confused what to make out of this now)?

Let's not try to fix every potential issue here I would say. We can always address that if we see someone sign-up as Mr. No Hats at a RIPE meeting and take him aside ... cluebats are great for providing some insight into a specific direction .. ;-)

Given that we only have indirect influence on the AGM decisions, I can see why the proposers wanted to have a safety net in the parts we get to control...

The proposers didn't wanted this safety net if I recall initially .. that came to the discussion after someone decided he wanted to request the complete number pool ... And he didn't even wanted to do so.. he just played with the idea that it would be possible ... This complete theoretic possible abuse for this specific policy has been entertained long enough I would say .. time to move forward. Regards, Erik Bais

On 13/01/2015 14:46, Gert Doering wrote:

...

So your suggestion would be to stall this proposal until we know what comes out of the next AGM, and then see if we need the clause in question at all, anymore? yes, that was my suggestion. The current configuration is stable, so there are no pressing operational reasons to change things in a hurry. If we're going to change, we need to do that's best for N years down the road, not what's best for a couple of months during 2015. I do not think it is a good idea to stall a policy proposal in order to see if the Board/AGM decides to take into consideration or ignore in the future your presentation/proposal from the previous AGM. I think your suggestion sets a very dangerous precedent where a policy

...

What if the AGM decides to bring back a yearly recurring charge for ASNs, we loosen up our policy, the AGM decides to remove the charge once again, from previous email:

...

...

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. Both the RIPE NCC membership and the AP working group tend to end up with reasonable policies. I'm pretty confident that this isn't going to change any time soon. It has already changed from a year to the other and that is why I did not like the proposal you made at the previous AGM. We need to have a charging scheme that is predictable and will not change from a year to

Hi Nick, On 13/01/15 16:57, Nick Hilliard wrote: proposal would be stalled pending a decision that may or not be taken at the next AGM. Regarding the current configuration, well.. it requires the requester of the ASN to come up with a reason that can not be verified by the RIPE NCC and with a predicted set of peers that may or not peer with the assigned ASN. For example, see the e-mail sent to the members-discuss mailing list yesterday by Shahin Gharghi; the current policy requires the requester to list the two ASNs they will peer with, what if some companies can not peer with two ASNs because of local regulations. Do you think that company should not receive the ASN they need? Also, from your e-mail I understand that you are sure the AGM will vote within 'a couple of months' to charge for ASNs. Do you know something that I don't? :) the other. I think that if this policy proposal becomes policy and too many companies start requesting 1000 ASNs, the AGM can react and start charging (either from the first, the second or the 100th ASN) based on numbers that the RIPE NCC will provide. I do not like the idea that a policy proposal can be stalled because someone can imagine a way the proposal/policy could be abused. If it does get abused, we react on that and not on predictions.

Nick

Regards, Elvis -- <http://v4escrow.net> Elvis Daniel Velea Chief Executive Officer Email: elvis@V4Escrow.net <mailto:elvis@v4escrow.net> US Phone: +1 (702) 475 5914 EU Phone: +31 (0) 61458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited.

On Tue, Jan 13, 2015 at 05:56:25PM +0000, Nick Hilliard wrote:

As a community, we managed to arrive at a practical workaround, namely that you can apply for an ASN if you have a plan to multihome and can state a name for a potential peering partner. We all quietly acknowledge that it might not match the spirit of the policy, but it works and has worked for as long as the RIPE NCC has existed. It needs to work because often an organisation needs an ASN even when they're not yet ready to multihome.

So, you admit that the policy, as it stands, is ineffective and is honoured in breach more than in observance. The proposed policy does not much more than put in writing the current practice anyway.

to what we want for the next 19, rather than put in place a temporary stopgap with the aim of plugging a leak. If this means being patient for another couple of months until RIPE71, then that's fine by me.

I'm not in favour of making policy at the meetings, not least because I rarely have the opportunity to attend and I consider this an attempt at disenfranchisement. Remember 2007-01!

Then you misread my email: I have no more information than anyone else about how people might vote.

Well I will vote against charging for ASNs, for one. Charging for something one effectively *needs* to operate smells of Ryanair-ish practice to me. What is your plan in case the members vote against this charge? rgds, Sascha Luck

Hi, There was a small ruckus on this mailing list about the 1000 ASN limit during the holidays. The whole disagreement is centred around the fact that ASNs are free now. I've read a lot of messages that seem to suggest that there should be some charge related to them that prevents amassing them in the billions. I sort of agree with that, but... Is there someone in this community that feels they should be completely free, no matter how many you have? I'd like to offer some more food for thought. These are not realistic suggestions, but I hope they will close the gap between the two debating sides: How many ASNs can a LIR get using one email or one click on the RIPE portal? My understanding is that even after 2014-03 is implemented, the answer will be one(1). After that email/click, the LIR will go through the Process. I don't think any amount of policy simplification will reduce the work required per Process Instance at both the LIR and the RIR below two minutes. In the crypto(slash)security community this is called the proof-of-work system. So, for a thousand ASNs this would mean about 33 hours. As we want to turn that into money, working at ten Euros per hour the cost would be 330 Euros. You can twist the numbers every which way, but it's hard to twist them so far that the result would be much smaller than Nick's example of setting up another company for 10 Euros (+work.) If we want to make sure that a LIR doesn't automate their email responses to the Process, we can include another random proof-of-work such as "what is the sum of the digits in today's date?", "how much is this ticket number divided by the number of ASNs you already have?" or "when do the cows come home to roost?" Or just a plain old CAPTCHA. Someone suggested that if the ASNs were free and someone got four billion of them, we can fix that post-fact by raising the ASN fee above zero. The same person, in the same sentence, also hinted that this special someone would be based at some tax haven sort of place, where exacting this fee won't really be possible, should the someone refuse to pay the new fee. The resulting reclamation process would leave us without ASNs for a couple of years. Then again, according to my above thesis of ASN acquisition speed, it would take thousands of years for the bad guy to finish all the Processes to get all the ASNs in the first place. There, a couple of cents worth... -- Aleksi Suhonen / Let bogons be bogons.

Hi Daniel,

That one strikes me as well. I don't know how often people arguing about ASN stockpiling really apply for ASN's but my experience is that it takes quite a lot of explanation even to get a second ASN for the same entity.

But maybe I am missing something here and the "non multihoming" rule means the NCC will not check anything at all in the future and just give away ASN's to anyone asking for them, no matter how many?

That is the basic idea: ask for another ASN and you'll get one. Then some participants on this mailing list were worried that someone might request the whole pool. That caused a new version of the proposal to be written with some limits in them. Those limits were chosen in such a way that even the organisation with the largest number of ASNs could request 10x as much as they currently have and still fit in the policy. It is however a 'magic' number. That caused some objections because the policy is now not as clean and simple anymore. So now this working group needs to decide in which direction to move: a very simple and clean policy that is 'ask and you will get', or a policy that places arbitrary limits just in case someone might try to abuse the policy. Or some other form of rate-limiting? If the RIPE NCC started charging for ASNs again then that would be a limiter and a reclaim mechanism. The policy could certainly remain a lot cleaner in that case. Or, just thinking out loud: we could allow the NCC to limit the number of resource requests they accept per week from the same organisation or something like that. With exponential back-off? ;) As a working group we need to decide a few things: - do we want to make it easy to get ASNs? (the answer seems to be "yes") - do we want to place a limit? - do we want a time-based or absolute limit? - do we wait for the next RIPE NCC charging scheme to see if that solves our problems? Cheers, Sander Steffann APWG co-chair

Hi Nick,

Op 19 jan. 2015 om 13:45 heeft Nick Hilliard <nick@inex.ie> het volgende geschreven:

...

On 19/01/2015 21:42, Sander Steffann wrote: As a working group we need to decide a few things: - do we want to make it easy to get ASNs? (the answer seems to be "yes") - do we want to place a limit? - do we want a time-based or absolute limit? - do we wait for the next RIPE NCC charging scheme to see if that solves our problems?

and:

- do we want to implement garbage collection for unused assignments.

Indeed! Sander

* "Sascha Luck [ml]" <apwg@c4inet.net>

On Mon, Jan 19, 2015 at 01:42:49PM -0800, Sander Steffann wrote:

...

- do we wait for the next RIPE NCC charging scheme to see if that solves our problems?

I'm not in favour of this. What I want to see is that the membership fee covers all my dealings with the NCC. In small companies, you often have to get budgetary approval for even EUR50, and I'm in *no* mood to explain to a bean-counter (or the boss's wife) what an ASN is and why I need 50 quid to pay for another one.

Hi Sascha, Would an ASN charge be more palatable to you if the membership fee included a quota of 1 (or N) gratis ASNs? Or perhaps that the already existing IPv4/IPv6 PI charge would include 1 gratis ASN per resource? I'm thinking that as long as N is a quite modest number, this does not cause any real abuse potential and at the same time it would make it more likely that the membership would agree to having an ASN fee put in place - as the vast majority of us won't actually have to pay anything more than we do today. (I'm well aware that this is outside of APWG's jurisdiction though. Just thinking out loud, perhaps some board members are listening...) Tore

On 20/01/2015 12:23, Sascha Luck [ml] wrote:

All in all, an unelegant solution. Besides, I like the idea of a "flat-rate" charging scheme where you pay yor membership fee and have all your services for the year covered.

that would be nice, except ASNs are assigned to end users not LIRs. A large number of end users with ASNs are not LIRs. Nick

On Tue, 20 Jan 2015, Tore Anderson wrote:

* Sander Steffann <sander@steffann.nl>

...

As a working group we need to decide a few things: - do we want to make it easy to get ASNs? (the answer seems to be "yes")

Yep. I'm not opposed to saying that the applicant must have *some* form of technical need for it. Multihoming would be one valid requirement, but it shouldn't be the only qualifying technical need.

Yes, that is where I thought we were. I was aware of the proposal to remove the multihoming as an absolute demand but I thought there would still be some kind of needs based delegation.

I liked the first version of the proposal...

Maybe I have some reading to catch up with. Cheers, Daniel _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm

On Tue, Jan 20, 2015 at 04:29:57PM +0900, Randy Bush wrote:

...

- do we wait for the next RIPE NCC charging scheme to see if that solves our problems?

think for a minute what price would have a damping affect while not being a pita to marjorie who just wants an asn to get her job done. there may not be a good price point that accomplishes both.

1 euro per year per ASN would already have a strong dampening effect

On 19/01/2015 02:28, Aleksi Suhonen wrote:

Is there someone in this community that feels they should be completely free, no matter how many you have?

we all want a free lunch.

I'd like to offer some more food for thought. These are not realistic suggestions, but I hope they will close the gap between the two debating sides:

How many ASNs can a LIR get using one email or one click on the RIPE portal? My understanding is that even after 2014-03 is implemented, the answer will be one(1).

(End Users, not just LIRs.)

After that email/click, the LIR will go through the Process. I don't think any amount of policy simplification will reduce the work required per Process Instance at both the LIR and the RIR below two minutes. In the crypto(slash)security community this is called the proof-of-work system. [example deleted]

this certainly creates work for the applicant, possibly enough to slow down the process of ASN acquisition. It also creates work for the RIPE NCC and someone needs to pay the RIPE NCC bills both to develop and to operate the system. This cost will be borne by the LIRs and as a LIR, I'm not much keen on funding this sort of thing. Also the proposal doesn't include any sort of garbage collection mechanism. In a situation where we face short-term depletion of the resource, this is important. Nick

On Mon, Jan 19, 2015 at 01:45:58PM -0800, Sander Steffann wrote:

I'm not sure we should create another garbage collection mechanism. I would prefer the NCC to implement the [2007-01] one

No thanks. The same heap of bureaucratic bullshit that is required to get PI space just to get an *ASN*? Not to mention the lulz that will result when a LIR applies for an ASN and the NCC refuses the request because the same entity can't be on both sides of the contract... Garbage collection can be more easily implemented, just request (annual?) confirmation the resource is still required, if the answer is negative, or there is none, reclaim it. (This could even be extended to PIv6) Also, what did I miss? When did ASNs become such a scarce resource that drastic rationing is required? rgds, Sascha Luck

On 20/01/2015 00:17, Sascha Luck [ml] wrote:

On Mon, Jan 19, 2015 at 09:32:50PM +0000, Nick Hilliard wrote:

...

we all want a free lunch.

TANSTAAFL. But *nobody* wants Ryanair, where you pay and then pay again. And again. And again.

yes, TANSTAAFL. Doesn't stop me from wanting it though.

...

this certainly creates work for the applicant, possibly enough to slow down the process of ASN acquisition. It also creates work for the RIPE NCC and someone needs to pay the RIPE NCC

I'm sure this scenario is not beyond the limits of automation. One ASN per LIR, then block any more requests for 24h (or whatever). Any of the NCC software bods want to comment on how hard this could possible be?

The primary consideration should be whether the proposed policy mechanism is sound rather than on how much it would cost the NCC to implement it. I'm not convinced that creating more bureaucracy in an explicit attempt to make it more difficult for people to apply for ASNS is a good basis for creating policy. Nick

On 20/01/2015 09:04, Elvis Daniel Velea wrote:

Are you sure this battle of yours is not so that you can go on one-week free trips to Bali paid by the LIRs? (like the IGF a couple of years ago)

Elvis, If you have concerns about the RIPE NCC member outreach program, it would be more appropriate to bring them up in a forum where they can be addressed properly, e.g. the ncc members mailing list, at a RIPE NCC General Meeting or directly with RIPE NCC management. Nick