Dears,

I oppose to the current policy proposal as written. It does not mean that a second version would not be acceptable but this one has a few major problems:

On 5/17/16 3:08 PM, Remco van Mook wrote:

Thank you Marco.

Dear colleagues,

Yes, this is another policy proposal about IPv4. It's even about the current allocation policy (confusingly known as 'last /8'). I'm sorry it's come to this.

The proposal doesn't aim to change a lot about the *intended* goals of the last /8 policy - instead, it tries to clarify the current policy and lock it down against creative interpretations.

This is true. However, it creates several problems and fixes only one. The fix - allocations from 'last /8' can not be transferred any longer (once this proposal is accepted and becomes policy).

We're in the IPv4 afterlife, and have been for about 3.5 years. The last scrap of IPv4 space that any LIR can get is meant for a specific purpose - to facilitate migration to IPv6. The age of the 32 bit integers is over. The other purpose of the 'last /8' policy is to be able to hand out IPv4 space to new entrants for as long as feasible. These specific purposes are currently not reflected anywhere once a block has been allocated, and this proposal means to change that. To summarise the proposed changes:

- All allocations handed out under the 'last /8 policy' will be (re-)registered as 'ALLOCATED FINAL';

All allocations (as in all those that were allocated since 2012?) or only the ones that are going to be allocated once this proposal becomes policy?

- Allocations marked as 'ALLOCATED FINAL' can not be transferred or sub-allocated;

I would agree with the 'no transfer' ban but do not agree with the no sub-allocation. If someone wants to 'sub-allocate', they can easily create assignments. This can not be enforced except if we forbid the creation of sub-allocated PA objects using business rules. But even if we use business rules, that will only block the creation of sub-allocation blocks to the LIRs that really want to follow every word of the policy, the abusers will continue to abuse.

- Any LIR can hold up to a /22 of 'ALLOCATED FINAL' address space, regardless of how they got it;

What if an LIR has already received a transfer of a 'last-/8' block. They have paid for it and the RIPE NCC has approved the transfer. Requesting those back would lead to the NCC being sued over and over again.

As we have discussed privately, you do not intend for this policy proposal to apply retroactively. If that is the case, then you need to figure out a solution for those that will have 2 or more 'last-/8' blocks before this proposal becomes policy. That is why I believe a second version is needed as this one is not clear.

- Any excess space will have to be returned to the RIEP NCC within 180 days (however I don't intend that this is applied retroactively);

If you want this not to be applied retroactively, it must be very clear in the policy proposal. It looks like it would not apply retroactively the way this proposal is worded but it's not very clear.

- DNS reverse delegation will be limited to the LIR itself, and is limited to a total of a /22 in space.

How can the NCC enforce this? Why should 'ALLOCATED FINAL' IPv4 blocks have specific rules regarding reverse delegation but not the rest? Will this not be confusing?

And, outside of policy but enforceable as business rules following from this policy proposal:

- No RPKI for any 'ALLOCATED FINAL' blocks over a single /22

- No routing registry entries for any 'ALLOCATED FINAL' blocks over a single /22

Just like with reverse delegation, I oppose to having 'special' rules for the routing of 'ALLOCATED FINAL' blocks.

Additionally, and this is the reason I mainly oppose, if this proposal would become policy it would force every single small company that needs IPv4 addresses for its operations to hire someone to handle the communication with the RIPE NCC, the routing and the reverse delegation for their 'last-/8 allocation'.

Currently most customers of LIRs are redirected to the RIPE NCC (to become LIRs and get a /22) if they need (a few) IP addresses. This policy proposal forbids the LIR to manage the address space of the small - newly created - LIR (their customer).

We currently manage and maintain the address space of several customers of ours (LIRs). This policy proposal aims to request each of our customers to hire their own IT team because an other entity can not manage their 'last-/8' allocation (but it's ok for the other allocations they hold).
Forbidding routing/reverse dns to be managed by the large ISP or a consultant is one of the big problems of this proposal. Also, this can be easily worked around and I doubt the NCC can even enforce this rule.

Basically, every LIR gets 1 allocation, and if you no longer need it or you end up having more, you have to return the excess. All the extra limitations should be workable if you're using the space the way it was intended, but make it unattractive to collect allocations for other purposes.

Let's hear your thoughts. I'll be at the RIPE meeting next week where I'll be talking about this proposal during the first APWG session.

NEWTEXT: 5.1.5: An allocation marked "ALLOCATED FINAL" is valid as long as it remains with the LIR it was allocated to. If an LIR, due to mergers, acquisitions or other means gains additional allocations marked "ALLOCATED FINAL", all but the equivalent of a single /22 will be de-registered by the RIPE NCC within 180 days.

Let's take the following example:

LIR A receives their 'last-/8' allocation in 2014.
In 2015 it transfers (transfer or merger) an other 'last-/8' allocation.
In 2016Q2 this policy proposal is approved and the RIPE NCC updates the RIPE Database objects. Now they have two 'ALLOCATED FINAL' blocks.
In 2016Q4 they want to transfer a non-last-/8 allocation, will they be forced to return one of the two ALLOCATED FINAL blocks?

If not, why?
If yes, how long do you think it will take until the NCC is taken to court?

NEWTEXT: 5.4: [...] Sub-allocations cannot be made from allocations with a status of "ALLOCATED FINAL". The meanings of the various "status:" attribute values are described in Section 7.0.

Why? What would be the difference between a Sub-allocation and an Assignment in this case?
Are we really adding stuff in the policy that works against the registration goal?

NEWTEXT 3.0: [...] For "ALLOCATED FINAL" IPv4 address space, authority may not be delegated to another party, and the reverse delegation will be limited to a total of a /22 of IPv4 address space.

How can this be enforced? Since when is the community or the NCC getting involved in how someone manages their network and/or reverse delegation?
Again, how long do you think it will take before the RIPE NCC is taken to court for implementing a policy proposal that forces new (small) LIRs (or even older, bigger ones) to cancel their contracts with their ISP or consultants for the management of their resources/LIR?

Kind regards,

Remco van Mook

(no hats)

Regards,
Elvis
(wearing a fedora while writing this reply)

On 17 May 2016, at 14:05 , Marco Schmidt <mschmidt@ripe.net> wrote:

Dear colleagues,

A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy"
is now available for discussion.

The goal of this proposal is to limit IPv4 from the remaining address pool
to one /22 per LIR (regardless of how it was received).
These “final /22” allocations will receive a separate status with several restrictions:

-    These allocation are not transferrable
-    LIRs may only retain one final /22 following a merger or acquisition
-    Sub-allocations are not possible
-    Reverse delegation authority can not delegated to another party

You can find the full proposal at:

   https://www.ripe.net/participate/policies/proposals/2016-03

We encourage you to review this proposal and send your comments to
<address-policy-wg@ripe.net> before 15 June 2016.

Regards

Marco Schmidt
Policy Development Officer
RIPE NCC