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

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.


> 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.

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.


> 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 ;)

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


> 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.


> 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.


> 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.

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


Richard