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

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
>