[address-policy-wg] address-policy-wg Digest, Vol 23, Issue 15
- Previous message (by thread): [address-policy-wg] 2013-05 New Policy Proposal (No Restrictions on End User Assignments in Intra-RIR Transfers)
- Next message (by thread): [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published(No Need - Post-Depletion Reality Adjustment and Clean up)(Tore Anderson)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Lu Heng
h.lu at anytimechinese.com
Wed Jul 24 19:50:05 CEST 2013
Hi Should the technical side of resouce training being done by ripe ncc training rather than policy? I am not against put basic principal there though. On Jul 24, 2013 5:27 PM, <address-policy-wg-request at ripe.net> wrote: > Send address-policy-wg mailing list submissions to > address-policy-wg at ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ripe.net/mailman/listinfo/address-policy-wg > or, via email, send a message with subject or body 'help' to > address-policy-wg-request at ripe.net > > You can reach the person managing the list at > address-policy-wg-owner at ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of address-policy-wg digest..." > > > Today's Topics: > > 1. Re: 2013-03 New Draft Document and Impact Analysis Published > (No Need - Post-Depletion Reality Adjustment and Clean up) > (Filiz Yilmaz) > 2. Re: 2013-03 New Draft Document and Impact Analysis Published > (No Need - Post-Depletion Reality Adjustment and Clean up) > (Tore Anderson) > 3. Re: 2013-03 New Draft Document and Impact Analysis Published > (No Need - Post-Depletion Reality Adjustment and Clean up) > (Filiz Yilmaz) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 24 Jul 2013 12:53:18 +0200 > From: Filiz Yilmaz <koalafil at gmail.com> > Subject: Re: [address-policy-wg] 2013-03 New Draft Document and Impact > Analysis Published (No Need - Post-Depletion Reality Adjustment > and > Clean up) > To: Tore Anderson <tore at fud.no> > Cc: "address-policy-wg at ripe.net" <address-policy-wg at ripe.net> > Message-ID: <FFF81C24-3E2F-4E44-8837-32D44B8B841D at gmail.com> > Content-Type: text/plain; charset="windows-1252" > > Hello Tore, > > While I am curious for Michele's response to your mail too, here is my > bit, as I feel I agree with him in terms of principles. > > First of all, I am not totally against your proposal; it cleans up the > policy text reflecting today's circumstances to some extent and it makes a > long document way more readable. > This is also why I am writing back because I've read the draft policy > document from the beginning to the end. > > 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. > > 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. > > 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. > > > My other concern is in regards to the transfers. As neatly put by the NCC > Board in the Impact Analysis: > > --- > 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. > Implementation of the policy could expose LIRs to legal challenges under > EU competition law. > --- > > > I think singling out the RIPE NCC region in the world of transfers may not > be the best idea at this stage. > > Kind regards > Filiz Yilmaz > > > > > On 24 Jul 2013, at 10:52, Tore Anderson <tore at fud.no> wrote: > > > * Michele Neylon - Blacknight > > > >> As previously stated, I do NOT support the "no need" policy and > >> cannot support this document. > >> > >> IP addresses are a finite resource, as we all know, and obliging > >> people to provide some level of justification makes sense. > >> > >> The argument for "conservation" may no longer be valid, but there > >> will always be a compelling argument in favour of good resource > >> management, which I believe the policy covers. > >> > >> RIPE should not remove the requirement to provide justification. > > > > Hi Michele, > > > > I doubt you'll find anyone in the working group who is against good > > resource management. I am convinced that the proposed policy is not in > > conflict with good resource management, otherwise I would never have > > proposed it. While I can obviously only speak with certainty for myself, > > I assume that the people who support the proposal feel the same way. > > > > While it appears you believe that the proposal will bring about poor > > resource management, your message neglected to explain why or how. This > > makes it rather difficult for me to try to alleviate your concerns. > > > > As Gert also pointed out recently, the main reason I believe that IPv4 > > would continue to be consumed responsibly under the proposed policy, is > > that the LIRs in the region are painfully aware that there is no more > > IPv4 to be had from the RIPE NCC. Should an LIR anyway decide to go on a > > "spending spree" with its remaining inventory, it would only end up > > hurting itself by expediting its own depletion date. The community will > > not be impacted - without a Common, there can be no Tragedy. > > > > Best regards, > > Tore Anderson > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > https://www.ripe.net/ripe/mail/archives/address-policy-wg/attachments/20130724/ba913f41/attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Wed, 24 Jul 2013 15:21:16 +0200 > From: Tore Anderson <tore at fud.no> > Subject: Re: [address-policy-wg] 2013-03 New Draft Document and Impact > Analysis Published (No Need - Post-Depletion Reality Adjustment and > Clean up) > To: "address-policy-wg at ripe.net" <address-policy-wg at ripe.net> > Message-ID: <51EFD4CC.9000006 at fud.no> > Content-Type: text/plain; charset=windows-1252 > > * 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 > > > > ------------------------------ > > Message: 3 > Date: Wed, 24 Jul 2013 17:27:06 +0200 > From: Filiz Yilmaz <koalafil at gmail.com> > Subject: Re: [address-policy-wg] 2013-03 New Draft Document and Impact > Analysis Published (No Need - Post-Depletion Reality Adjustment > and > Clean up) > To: Tore Anderson <tore at fud.no> > Cc: "address-policy-wg at ripe.net" <address-policy-wg at ripe.net> > Message-ID: <965997CB-07D2-49B9-BD9A-74E230F13724 at gmail.com> > Content-Type: text/plain; charset=windows-1252 > > Hello Tore, > > Thank you for your detailed e-mail. > > In order not to have people get lost between our inline comments, I will > only attempt to respond to you taking quotes from your mail. > Apologies if this distorts the logical thought process you had put in. > > > The > > language regarding registration requirements is not changed, so the > > proposal does not change anything - it merely upholds the status quo. > > Those principle based registration and address management requirements > were in the old policy between the lines, pointing to people notions like > anti-hoarding practices through "need based" requirements. They may not > ensure certain things 100% (policy is a policy, some abide some work > around?) but surely they serve as gate-keepers for good behaviour and > reflect the principles that this community engaged itself so far. > > So once you take those bits out, you also take those notions and > principles out of the policy. That was my point and so I disagree that your > proposal does not change anything. In fact it is bringing a big change, > changing address delegation from "I want it because I need it on a network" > to just "I want it and I am a member of the RIPE NCC so I can get it and > maybe i won't even use it on a network". > > > What constitutes "good address management" is something > > left to the LIRs to decide for themselves. > > I tend to disagree with this too. LIRs are members of the RIPE NCC but > policies are developed by the entire RIPE Community, which is a bigger > stakeholder. > Those views should be reflected in the policy to be remembered and > documented by the LIRs. > > > 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. > > I see your point but policy does not mean "policing". To my knowledge, > RIPE NCC never sent agents to LIR premises to check if the justification > they documented fit with the reality or not. Besides that the address space > is assigned to Red Cross or to a spammer (so who the recipient is) is > irrelevant and has always been in the eyes of the RIPE policy. But whether > or not either of these networks really needed these resources was the main > idea. > > And this still does not mean that policy is not going to be there to > remind people that this is a common pool of resources we are dealing with > and its management requires some degree of responsibility. We might as well > then not have a policy document at all and just have a click, pay and get > your resource button on the RIPE NCC website. > > > > 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 > > > These are not brand new principles, need base was there and your proposal > is taking this away. > I agreed with you when you presented your proposal in Dublin and noted it > is not efficient to request someone to breakdown their need in such detail > as 3 months to 1 yr or so. Yes, agreed, this is bureaucratic, admin > resource hogging etc and this needs a change. > > But the same policy should still make some sense in a region why an LIR > would go request some resource from their RIR and would be given that in > the first place. > If I am an LIR and I go to the RIPE NCC and ask for a resource I should be > needing it on *some* network, not to put in my IP collection drawer. > Policy should be the guard, gate-keeper for this at the least, in my > opinion. > > > >> * 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. > > > I am not a lawyer, but hypothetically speaking, if your proposal gets > accepted there is some (again totally hypothetical?) potential that some > LIRs may chose to rush and get whatever is left in the NCC pool (which is > the rest of the last /8?) without really needing them, simply because they > do not need to show any justification after all. They want it, they will > get it and probably RIPE NCC will have to deal with some very serious First > in First Out (granted) service scheme... > > And then these LIRs who were lucky to get all the space they wanted and > the RIPE NCC could provide to them at the time, may chose to put these > resources back in the market for others, end users or other LIRs. I would > find this quiet an unfortunate environment for new entrants who are not > LIRs yet at the time of your proposal gets accepted, but who really need > the space and is left to get the resources from an LIR instead of an RIR > whose job was the allocation of the resources in the first place. > > I believe thinking about the impact here in the light of competition laws > like this may in fact have some ground. > > Kind regards > Filiz Yilmaz > > On 24 Jul 2013, at 15:21, Tore Anderson <tore at fud.no> wrote: > > > * 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 > > > > > > > End of address-policy-wg Digest, Vol 23, Issue 15 > ************************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.ripe.net/ripe/mail/archives/address-policy-wg/attachments/20130724/4daab8ee/attachment.html>
- Previous message (by thread): [address-policy-wg] 2013-05 New Policy Proposal (No Restrictions on End User Assignments in Intra-RIR Transfers)
- Next message (by thread): [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published(No Need - Post-Depletion Reality Adjustment and Clean up)(Tore Anderson)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]