[address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)

Hi Richard,

On 9/27/13 1:45 AM, Richard Hartmann wrote:
> On Fri, Sep 27, 2013 at 12:24 AM, Elvis Daniel Velea <elvis at v4escrow.net> wrote:
>
>> These were restrictions that existed in the previous version and things
>> seemed to work well with these restrictions/sizes. I hear you and if others
>> think the same, we could change the limits.
>
> If /32 becomes the new default/minimum, keeping those limits seems to
> be counter-intuitive.
>

correct, let's see what the others think as well.

>
>> Well, someone that does not plan to make any sub-allocations or anyone that
>> still thinks that a /48 will be large enough for the foreseeable future can
>> request a /48. A /32 is provided by default though, so I would not see many
>> organisations specifically requesting a /48 and not the default /32.
>>
>> see 5.1.2:
>>
>> "5.1.2 Initial Allocation Size
>> [...]
>> /48 allocations can be made by the RIPE NCC to End Users that do not expect
>> to ever need more or for special purposes.
>> Special purposes are covered in section 6 of this policy. When an
>> organisation requests a /48 allocation, it must specifically mention in its
>> request that it does not plan to use anything larger in the foreseeable
>> future."
>
> True; I missed the crucial part of allowing "/48 allocations [...] not
> expect to ever need more". Sorry, it seems my comb hasn't been
> fine-toothed enough...
>
> Aside from the difference between "ever need more" and "foreseeable
> future", this means that End Users will need to decide between /48 and
> /32. To pick a specific example, FOSDEM will apply for IPv6 PI soon.
> As they need more than one single /48, under that policy the seem to
> be _forced_ to a /32.

Well, it's a /48 if you are sure you will never need more; otherwise, 
you can get the /32, as everyone else.

>
> With a corporate hat on, I think it highly unlikely that anyone
> manager or sales person will be content with less than the absolute
> maximum they can get even if they don't need it. So save for a few
> corporations and maybe temporary allocations, I suspect everyone will
> go for a /32.
>

I suspect the same, I did not want to introduce arbitrary limits between 
/48 and /32. I think these two limits are enough and adding an other one 
would complicate the policy.

>
>> That was our main concern, so.. I already approached a few of the Board
>> Members to discuss this policy proposal and at least announce them that this
>> is coming.
>>
>> My idea was that while the AP-WG can not do anything about the fees (these
>> are decided by AGM) we (the proposers) can discuss during the AGM our
>> following idea:
>>
>> - if the policy proposal gets good feedback from the community, it would be
>> a great exercise to ask the RIPE NCC (Board) to calculate how much would a
>> /32 cost if the prices would be leveled..
>>
>>     - if the price can not be leveled yet, see how much would the membership
>> fee decrease if the non-LIRs would pay double the current price (100€) or
>> 500% more (250€), or something around that price.
>
> That's great to hear.
>
>
>> I had this idea initially. But, then how do we determine how large should
>> this allocation be? By taking an arbitrary number? What if this number is
>> not longer the right number in 2 years?
>
> Then we change policy to adapt ;)

The idea of this policy proposal is that we would like to fix it and not 
need to change it every year or two.

>
> But I see your point and I was not really happy when coming up with /40 or /41.

Exactly, in the discussions with the other proposers I had also the /40 
in mind. But this number is so arbitrary that it will help some and not 
help others. Let's not put arbitrary numbers in policies. If you need 
IPv6, you can get as much as you want (even if you are not an LIR). But 
then, the price for (each) allocation will need to be close to the price 
an LIR pays for the same IPv6 allocation.

>
>
>> I think this is where we should be looking at. Try to get the 'price per
>> /32' to be equal (or almost equal) to both members and non-members. You get
>> a block, you pay the same price for it whether you are a member or not.
>> Maybe not immediately, maybe not in the next 2-3 years.. but this should be
>> the goal for the future.
>
> If it's not done after one year at the latest, I fear that would breed dissent.
>

I think that we have two options:
1. ask the board/NCC to calculate what would be the price per allocation 
if there would be no difference between LIRs and non-LIRs
2. start with a step-by-step approach - as we do not have that many 
non-LIRs using IPv6 now, I think that the increase from 50 to (arbitrary 
number from my mind) 500 Euro would be pretty high. The idea would be to 
come up with a plan that in 3-5 years the price for a /32 to be the same 
for members and non-members

>
>> However, I remember that 'charging per prefix size' discussion did appear in
>> some of the previous policy proposals and if I remember correctly we were
>> told that if the RIPE NCC were to charge based on prefix size, it may lose
>> it's not-for-profit status that it has with the Dutch authorities. We need
>> to be careful so that we do not affect RIPE NCC's status and activity.
>
> Good point; that makes arbitrary cut-off points (/40) appear more
> appealing, again.
>

let's see what the NCC and the Board will say about this in the Impact 
Analysis.

>
>> I agree, but let's keep this discussion in the ncc-services-wg, please.
>
> AFAIU, the general point of "this proposal is needlessly hard to read"
> does belong on this list. I am willing to bet that easier consumption
> will translate directly into more feedback.

Correct, the page could have been formatted better. I would not change 
it now, as we have already started the discussion. I will talk to the 
NCC if there is a version 2 and the page will clearly show the 
differences between the current policy and proposed changes.

>
> You are right that the rest of this discussion does not belong here, though.
>
>
> Richard
>

cheers,
elvis