[address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up)

Dear Tore,

I am aware of all the practical examples you have provided. 

You keep saying that everything but one thing is the status quo already but that one thing bares a whole notion and a principle (beyond maths) that I have been trying to express in my previous posts because I simply do care about it. 

Few points of clarification about my own thoughts so far instead of someone labelling them for me too:

- Yes, I already agreed with certain things you are proposing, true. I've explained why. 
- I know what an allocation and assignment is.
- I am not against transfers but I am against the practice of getting space now from the NCC just to be able to transfer it later. 
I do not call this a best practice and I would not like RIPE Policies encourage it. 
- But I find transfers extremely useful if they are to bring out some already allocated space out of some drawer.
 
While the current system is based on trust, there is definitely enough of wording for what that trust is to be in the current text. 
It is my belief that your proposal is taking them out all together and leaving the resulting document a mere description of a system that is an IP market, removing the core essential that IPs are for networks in the first place. This is where my concern lies, not about removing the bureaucracy. 

You seem to say that you want to change the annoying step 6 in your John Q example, where everything else is going to stay the same anyways. 
ripe-583 may be an overkill today, agreed. It is just a form and a practice NCC applies though as a result of their interpretation of the policy. 
If it is a problem ask the NCC folks to come up with a more efficient form or a new scheme or totally have it removed even. 
Policy document does not talk about ripe-583 specifically anyway. 
But your proposal is removing way too many important principles from the policy text in order to fix an operational problem. 

In other words, the way it is written, the resulting text and so your proposal is taking it to the extreme, doing more than just removing the unhelpful bureaucracy in my opinion.
This is not a matter of an other proposal that can be made after yours. This discussion is happening to note these about this proposal. 
 
I may be just one person who thinks we should still mention in the resulting document that RIPE Community cares about networks, that we do realise that IPs are for networks and that these are expected to be used with care and responsibility. And so this is my input to the current discussion.

I hope it is now clear what I am opposing to and what not. 

Kind regards
Filiz Yilmaz




On 25 Jul 2013, at 09:32, Tore Anderson <tore at fud.no> wrote:

> Filiz,
> 
>> According to the current policy your main reason to request an IP 
>> address must be that you need it to use on a network.
> 
> This is only the true for *assignments*, not *allocations*. This is a
> subtle, but important, difference.
> 
>> As soon as you remove this, that the IP address is actually needed
>> on a "network" (network can be LIR's or End Users, does not matter),
>> you make them a commodity. As soon as you do that within your policy,
>> you stamp that they actually are money making assets to be turned
>> into some value now or later and this practice is all fine according
>> to the policy too.
> 
> We have *today*, under our current policy:
> 
> - An allocation transfer policy that has no restrictions on monetary
> compensation being exchanged between the parties to a transaction;
> - A list of «Recognised IPv4 Transfer Brokers» published by the NCC;
> - A NCC-operated "lightweight self-service IPv4 broker" or "bulletin
> board" aimed at helping LIRs interested in trading find each other.
> 
> 2013-03 takes no position whether or not all of this is a "good thing",
> nor do I. But let's face the facts, it's *already there*.
> 
>> This means an LIR can request these resources to do whatever they
>> want to do with them including requesting them not to be used on any
>> network of their own or an End Users' at all but for some other
>> reason. One of these reasons will be deliberately passing them on to
>> a paying 3rd party who may or may not use them on any other network
>> either.
> 
> This is *already possible* today; in fact, what you're describing above
> is pretty much the core function of an LIR.
> 
> Let me try to explain by making an hypothetical example:
> 
> Background: John Q. Public wants to make money on IPv4. He has a laptop
> and and e-mail account, but no networking equipment, nor an internet
> connection of his own; in fact, he's leeching off his local coffee shop
> gratis WiFi in order to get online. John then does the following:
> 
> 1) Incorporates "JQP IPv4 Leasing Company" in his local jurisdiction.
> 2) Joins the NCC and pays the membership fee, thus becoming an LIR.
> 3) Requests and receives an IPv6 allocation, ignores it.
> 4) Requests and receives his "last /8" /22.
> 5) Sets up an auction or something like it, and finds the end user(s)
> willing to pay the most for [parts of] the /22.
> 6) Gets a completed ripe-583 form from the auction winner(s), forwards
> it to the RIPE NCC (if he does not yet have an AW), and saves a copy in
> an archive folder.
> 7) Assigns the address space over to the new end user(s) (i.e.,
> registering ASSIGNED PA inetnum objects in the RIPE database).
> 
> So, again, this would be *already possible* and completely legitimate
> under our current policy. If John manages to get higher income from his
> customers then what he's paying the NCC in membership fees, then voila!
> John is making money off IPv4, without having ever forwarded a single
> IPv4 packet on behalf of his customers.
> 
> Again, 2013-03 takes no position whether or not this is a "good thing",
> but it is the status quo today, so when discussing the proposal, I think
> we should try to keep on-topic, i.e. discussing what the proposal
> actually *changes*, which in the above case is the removal of point #6
> and nothing else:
> 
> John's customer won't have to fill out the ripe-583 form anymore. This
> is a good thing at least in one way, because it removes a bureaucratic
> overhead that would otherwise impose a work load on John, John's
> customer, and the RIPE NCC. I think you referred to it as "admin
> hogging" in an earlier message and I couldn't agree more.
> 
> Your concern is that by removing point #6, it becomes possible that the
> winner(s) of John's auction does not "need" the space, yet are able to
> receive it. I concede that this is theoretically possible. But I remain
> unconvinced that this is an *realistic* problem - I simply don't see why
> someone would bid on address space that they don't "need", especially
> when they have to outbid a bunch of others who *do* have potentially
> quite desperate "need".
> 
> And even if such actors do exist and do outbid all the folks that do
> "need", keep in mind that *today* 1) the entire system is trust-based
> and that 2) John has absolutely no incentive to undertake a deep
> investigation into whether or not his customer's ripe-583 form is
> truthfully filled out or not - if it looks credible enough, his job is
> done. He could also make a habit of forwarding the forms to the NCC to
> get "official" stamps of approval.
> 
>> I do not think this is good practice or responsible address 
>> management.
> 
> Maybe, maybe not - but it is what we have today. If we want to ban paid
> IPv4 allocation transfers and assignments because it's these do not
> constitute "good practice or responsible address management", then we as
> a community can do that, but please let's keep that discussion in a
> separate proposal.
> 
>> And so in fact I am curious what is the rush of this proposal now 
>> that RIPE NCC is allocating from the last /8 and that soon it will
>> be exhausted anyways and what is wrong with keeping what we have as 
>> policy as long as this last bit of /8 lasts.
> 
> Your definition of "soon" differs wildly from mine, or you haven't done
> the math. Allow me:
> 
> - Number of /22s in 185.0.0.0/8 (sans the /16 for IXPs): 16320
> - Number of LIRs that held allocations outside 185/8 at the time of
> depletion (these are the only ones who can get their last /22 as an
> additional allocation): 7912
> - Number of reclaimed space held by the NCC as of today, in /22s: 903
> - Number of reclaimed space held by the IANA as of today, divided by 5
> RIRs, in /22s: 3731
> 
> In other words, there is a total of 13042 /22s to be given out to new
> LIRs under the last /8 policy (and this number keeps increasing as the
> IANA and the NCC continues to recovers space). As of today, there are
> 959 LIRs who hold *only* a /22 from 185/8. 314 days have passed since
> IPv4 depletion.
> 
> So how long will the last /8 last us based on the current usage rates
> and available space?
> 
> 13042 / (959 / 314 * 365) = 11.7 years
> 
> I truly hope that we've gotten IPv6 properly out the door by then...
> 
> To answer the second question, "what's wrong with keeping what we have":
> About half of the current policy text is describing out of date
> concepts, is self-contradictory or otherwise wrong, and that it imposes
> a bureaucracy on the community that demands that hundreds of thousands
> forms be filled out every year, all in the name of delaying something
> which has already happened.
> 
> I mean, you even said it yourself in an earlier message: «Yes, agreed,
> this is bureaucratic, admin resource hogging etc and this needs a
> change» - and I could not agree more, this is *exactly* why I have
> proposed 2013-03.
> 
>> Finally Gert seems to get my point with his example of someone going 
>> through the effort of opening 5000 new LIRs. I am not saying this 
>> will happen but even someone going to through the effort of opening 
>> maybe 2 or three just to get more address space for the wrong
>> reasons should be telling us something that our policy is missing
>> some core notion, that notion being IP addresses are mainly there to
>> be used on networks as soon as they leave an RIR pool.
> 
> I believe Gert's point was that you can open 5000 LIRs in this manner
> *today*, under our *current* policy. 2013-03 brings no change.
> Therefore, this is not a valid argument against 2013-03.
> 
> If you want to close this loophole, then that's food for another policy
> proposal. Opposing 2013-03 won't do anything about it, one way or the
> other (nor would supporting 2013-03).
> 
> (That said, in the current data there's no evidence of someone
> attempting to use this loophole in the described manner. Personally I
> believe that the NCC's membership fee is a sufficient deterrence against
> it.)
> 
> Tore
>