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

Dear colleagues,

During RIPE 72, the RIPE NCC was asked to suggest a way forward with 
regards to the unclear situation arising from address blocks in the RIPE 
Database with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. We want 
to give you an update on this work and ask for your input.

BACKGROUND

Although PI assignments made by LIRs have the same status in the RIPE 
Database, it is not clear if resource holders with assignments from LIRs 
have the same rights as resource holders with those issued by the RIPE 
NCC. The community, mainly End Users, has asked the RIPE NCC to clarify 
the situation.

In the early days of the RIPE NCC, a small number of LIRs received 
allocations with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. From 
these address blocks, LIRs could assign ranges with the status ASSIGNED PI.
The RIPE community later decided that the RIPE NCC should be the only 
party assigning ranges with ASSIGNED PI to End Users. It was not clear 
what the status of the assignments that had already been made should be.

ACTION TAKEN

At RIPE 71, the Address Policy Working Group asked the RIPE NCC to check 
the actual assignment status with the holders of these allocations. We 
contacted all of the LIRs involved and around 50% said they had no 
contact with holders of assignments with the status ASSIGNED PI within 
their allocations. Several allocations containing only PA assignments 
were converted from ALLOCATED UNSPECIFIED to ALLOCATED PA following 
communication with LIRs.

The RIPE NCC presented these results to the Address Policy Working Group 
at RIPE 72. The WG stressed that data accuracy must have the highest 
priority. It was further suggested that the RIPE NCC should follow up 
with the LIRs on a case-by-case basis, following the principles outlined 
below.

The WG agreed that, where the LIR can document a mutual agreement that 
they administer the address space, a conversion from PI to PA should 
take place. In all other cases, assignments with the status ASSIGNED PI 
should be treated as being assigned by the RIPE NCC.

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

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.

After the LIRs have finished their research, the RIPE NCC will:

-    Convert assignments to ASSIGNED PA if it can be documented that the 
administrative responsibility lies with the LIR
-    Follow up directly with resource holders of ASSIGNED PI to apply 
the RIPE policy, “Contractual Requirements for Provider Independent 
Resource Holders in the RIPE NCC Service Region”. The PI assignments 
will become part of the address space managed by the RIPE NCC just like 
all other PI space. Once the resource holders have fulfilled the 
contractual requirements, they will have the same rights and obligations 
as any other End User of PI space.
-    Split the allocations to separate the PI assignments and convert 
the blocks that remain with an LIR to ALLOCATED PA.

We suggest giving these LIRs until the end of January 2017 to clarify 
the status of the assignments within their ALLOCATED PI/UNSPECIFIED 
allocations.

In situations where a dispute arises between the LIR and the assignment 
holder about the administrative responsibility, the RIPE NCC will do its 
best to support a fair solution.

We welcome your feedback on this suggested approach. Please provide your 
input before 12 September 2016.

Kind regards,

Ingrid Wijte
Assistant Manager Registration Services
RIPE NCC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160804/e21cfa82/attachment.html>