[address-policy-wg] address-policy-wg Digest, Vol 23, Issue 15

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: </ripe/mail/archives/address-policy-wg/attachments/20130724/4daab8ee/attachment.html>