[address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED

On 04.08.2016 09:39, Ingrid Wijte wrote:
> It was also stated that LIRs should not register any new assignments with
> the status ASSIGNED PI, as policy no longer allows for new IPv4 PI assignments
> (with the exception of IXP PI assignments from our reserved address pool).

Does the current policy really states, that new IPv4 PI can't be made out of 
those assignments? I only read "The RIPE NCC no longer allocates or assigns
PI address space".


> APPROACH
> The RIPE NCC will contact the 38 LIRs holding allocations that contain
> address blocks with the status ASSIGNED PI (3,600 inetnum objects in total).
> In the following months, these LIRs will check if their RIPE Database entries
> are still correct. Each LIR will check their records and with their customers
> to see under what conditions the assignments were originally provided.

Before that you said 50% don't have any contacts with the end-user, holding
the PI. Who will be in the lead to contact those parties?


> Split the allocations to separate the PI assignments and convert the blocks
> that remain with an LIR to ALLOCATED PA.

That's the ugly part I don't like, but I'm biased.

For those few of us being long enough around to have such allocations and
with my current reading of the policy, you take away from us the possibility
to assign PIs to end-users ... fair enough, if my reading is incorrect, this
is not relevant anyway.

But splitting current A-PI/-U is as such not really a nice thing. It will
leave the initial holders of the ranges with little fragments. True, 
nothing which cannot be handled, but if I announce e.g. a /16 or have to
announce 50+ (or more or less) /20-/24s, it makes a difference (operational
and financially). Yes, more filters, reverse zones, ROAs, ...  Yes, everything
is possible, but I don't like it.


OTOH, I understand the wish of the community -and support it-, to treat all
PI owners equal ("Contractual Requirements for Provider Independent Resource
Holders in the RIPE NCC Service Region") and the end-users request to 
maintain their PI inetnum on their own. Even for the party with the A-PI/-U
it might be a relieve no longer discussing and maintaining the PIs of 
non-customers.


If I would have a choice, I would prefer RIPE NCC to think about how to
lock PIs within these special allocations to allow the end-user to manage
their PIs directly, force them to comply to the "Contractual Requirements",
locking out the A-PI/-U owner to touch the inetnums of PIs ... but this 
probably will not work out or be too "complicated" or come with side effects
someone will complain about later (e.g. the less-specific route object of
the A-PI/-U holder, the A-PI/-U holder's ROA for it).


TBC
Markus


PS: Yes, KPN's LIR have A-U. Thus I'm biased. But I know how bad it feels
suddenly having to announce and handle smaller fragments instead of the
full allocation, as a lot of address space (most of the AS517/AS286, Xlink/
EUnet allocations) moved to other KPN departments, leaving us (AS286) with
some more specifics ... and yes, sometimes you have to pay per prefix ...

-- 
Darmstädter Landstrasse 184      | 60598 Frankfurt        | Germany
+49 (0)178 5352346               | <Markus.Weber at kpn.DE>  | www.kpn.de

KPN EuroRings Germany B.V.       | Niederlassung Frankfurt am Main
Amtsgericht Frankfurt HRB99781   | USt.IdNr. DE 815496855
Geschäftsführer  Jesus Martinez  & Jacob Leendert Hage