* Filiz Yilmaz
My observation is that the new document proposed is not exactly a "registration" policy document. It more looked to me like a description of how address space management is done within RIPE NCC region "by the RIPE NCC".
If I am not missing anything crucial, the main points described are:
- The language is English, - How big an allocation can be, - That there is no PI anymore to be assigned directly from the NCC pools to End users (except for the IXPs) so all resources will only goto LIRs - And these blocks can be transferred between LIRs.
The only bit about registration I see in the new text is section 4.0 Registration Requirements and it does not go more than saying details should be recorded in the database.
So it does not contain any substantial information for registration or address management on the LIR's side.
Hello Filiz, The proposal is a modification of the existing policy document (ripe-592), it is not a brand new document written from scratch. The language regarding registration requirements is not changed, so the proposal does not change anything - it merely upholds the status quo. We can certainly discuss amending the current registration requirements, but to me this topic does not seem germane to the discussion of 2013-03.
This is interesting as now with this proposed policy any End user's chance to get any IPv4 address space will be through an LIR and hope that these LIRs are responsible and know what they are doing. I would like to see some guidelines or at least principles mentioned in this document so the LIRs know their responsibility in terms of fair address management as well as the End Users so they know what to expect from these LIRs. This is what I would be expecting from a transparent documentation of a set of policies and principles that are still in place.
We may not have too many specific policies to set for the few left-over resources but I would like to believe we still have "principles" towards the responsible management of these resources.
In that sense Michele has a point and I argue that LIRs need to be guided for "good address management" even without the "conservation" principle as the top priority in the new IP world. This is missing in the proposed policy text for it to be considered as a helpful "registration" policy in my opinion.
I have no problems being sympathetic towards a "good address management" principle, but the simple fact is that this is not written down in our current policy. What constitutes "good address management" is something left to the LIRs to decide for themselves. Example: As a LIR, you are today free to assign your last free IPv4 block to a group of spammers at the expense of having to turn down the Red Cross, perhaps because the spammers were willing to pay you more. Is that "good"? I'd say quite the opposite, but yet it is perfectly allowed by today's policy. So while I'm all for discussing the codification of a set of principles in our policies telling our community to be "good", I'd rather not weigh down this proposal with the addition of a brand-new "principles" section, which I suspect would require a lot of back-and-forth word-smithing to make everyone happy. So if we do want such a section, let's add it in a separate proposal.
In practice, I can set up a new LIR now and ask for a new allocation and I may be someone who does not have any previous RIPE or RIPE NCC experience. If all I have is this document, I am not sure if it tells me enough about my responsibilities, while I will be a critical token in the EU address management and registration system by just becoming an LIR.
As a new LIR, all the IPv4 address space you are going to get from the RIPE NCC is a /22, or 1024 addresses - hardly a «critical token in the EU address management and registration system» by any stretch of the imagination. This is the status quo today, and this proposal merely upholds it. I also find it rather hard to believe that an organisation willingly joins the NCC to become a new LIR, acquires an IPv6 allocation, and finally requests its first and only IPv4 /22 - only to find itself confused about how to go about using it in a sensible manner and end up assigning it away to an end user without any actual operational need.
* As mentioned in previous sections, the policy proposal would negatively affect the ability of LIRs to engage in inter-RIR transfers, as the RIPE NCC’s service region would be the only one without a needs-based requirement for transfers.
I feel this statement is somewhat disingenuous. The "odd RIR out" here is really ARIN, who is the only one to have a inter-RIR transfer policy that has a needs-based requirement that is also applied to the other region involved in the transfer. The RIPE region does not have a inter-RIR transfer policy *at all*. The same goes for LACNIC and AfriNIC, AFAIK. So as things stand today, 2013-03 cannot possibly "negatively affect the ability of LIRs to engage in inter-RIR transfers" because such transfers are completely verboten in the first place. That said, there has been an inter-RIR proposal (2012-02) on the table for a while now, but the community does not seem to want or care much about it. I think that this is important to keep that in mind when deciding on how much weight to give this argument against 2013-03. APNIC does have a inter-RIR transfer policy, but it does not require the other region to have a needs-based requirement. It explicitly states in section 4.3 that for transfers where the recipient is in another region, any conditions on the recipient is up to the recipient's region to define. So (assuming for a second that 2012-02 has passed) 2013-03 will not have any negative impact on transfers between the APNIC and RIPE regions. Another quite interesting thing to consider here is that APNIC initially had a transfer policy that did not require any need evaluation. It was only after the ARIN community changed their inter-RIR policy to explicitly require the other region to have "needs-based" policies APNIC added the need evaluation requirement to their general transfer policy. I think it is interesting to consider if yielding to the ARIN demand would actually be worth it, and APNIC actually provided some relevant data in this regard - on May 15th 2013, one of their reps explained to the APWG session at RIPE66 that there had been 11 inter-RIR transfers between ARIN and APNIC. APNIC depleted their IPv4 pool on the 19th of April 2011. Contrast this to the number of assignments that are being made in our region: The NCC reported that between depletion on the 14th of September 2012 and May 10th 2013, 251,254 assignments had been registered in the RIPE database. If we do linear extrapolation of the above to get "per year" numbers, what this boils down to is that we ask the entire RIPE community to fill out, validate, and archive 386,327 ripe-583 forms per year to allow 5 LIRs to engage in inter-RIR transfers with the ARIN region. You be the judge if this passes your idea of a basic cost-benefit analysis. It certainly doesn't pass mine. I'm not at all principally opposed to inter-RIR transfers, so if the author of 2012-02 would add a "need compatibility clause" to the proposed inter-RIR policy, I would have nothing against that. In other words, if it would be possible to make the need evaluation a voluntary thing that you only had to do if transferring addresses from the ARIN region - fine. Then those 5 LIRs, and those 5 only, could subject themselves to whatever demands the ARIN community might have, while the rest of us would be free of the IPv4 bureaucracy. Win-win.
* Implementation of the policy could expose LIRs to legal challenges under EU competition law.
If an LIR is willing to engage in unlawful anti-competitive practises, it will of course be exposed to legal challenges. This is certainly nothing new brought on by 2013-03 - the law trumps *any* address policy we can produce here, and that's how it's always been and always will be. Furthermore, it makes absolutely no sense to me for the community to demand that every single LIR and End User in the community uphold the "need" bureaucracy in an attempt to somehow shield or indemnify "bad" members of the community engaged in anti-competitive practises from legal repercussions.
I think singling out the RIPE NCC region in the world of transfers may not be the best idea at this stage.
This "world of transfers" has failed to materialise. The actual statistics show that the second-hand IPv4 transfer market is at most supplying 3-4% of last year's (pre-depletion) demand in our region. If we had completely removed the entire transfer policy today, I think that as far as the internet is concerned, tomorrow would have been business as usual. It seems that for most folks dealing with IPv4 depletion, CGN is the solution, not transfers. I think Rob Blokzijl hit the nail straight on the head when he in the RIPE66 APWG session warned against getting bogged down with discussing the ins and outs of «little add-on policies like transfer». After all, this proposal is a large and rough clean-up - it will be much easier to fine-tune and polish the remaining policy afterwards (transfers, PI/PA merging, etc.). Like I've said before, this proposal is essentially the amputation of the policy limbs that died following IPv4 depletion, and any following cosmetic surgery is best left for later. Best regards, Tore Anderson