[address-policy-wg] ALLOCATED PI / UNSPECIFIED next action

Hello working group,

The discussion on how the RIPE NCC should deal with ALLOCATED PI / ALLOCATED UNSPECIFIED has died down a couple of weeks ago. We therefore think that it is time to draw conclusions.

A total of 16 people and the working group chairs participated in the discussion following Ingrid’s proposal on how to handle the situation of PI assignments within ALLOCATED PI / UNSPECIFIED. Five people (Sergey Myasoedov, Radu-Adrian FEURDEAN, Nick Hilliard, Leo Vegoda and Hank Nussbacher) created side-threads without expressing an explicit opinion on the proposal.

The remaining 11 people were:
−    Patrick Velder
−    Larisa Yurkina
−    Randy Bush
−    Enno Rey
−    Herve Clement
−    Stefan Schiele
−    Markus Weber
−    Carlos Friacas
−    Leo Vegoda
−    Andre Chapuis
−    Daniel Stolpe
−    Oliver Bartels

Four participants stated that they represent organisations holding such allocations (Larisa, Markus, Andre and Daniel).
Three people indicate that they are related to PI assignments within such allocations (Enno, Stefan and Oliver).

Five people stated their clear support for the proposal (Enno, Stefan, Oliver, Patrick and Herve), mainly to increase clarity for PI assignment user and to support correct registration.

While there was no explicit opposition, Larisa and Andre stated that it would create extra workload for their organisations while they don’t really see the gains of such change. Larisa suggested to introduce alternative RIPE database statuses instead.

The other participants had mixed opinions:
Markus understands the advantages for PI assignment users, but was concerned about the extra workload for his organisation. He suggested to somehow lock PI’s within the allocations and force the PI holders to sign contracts, but recognized that this idea might be not practicable.
Daniel could life with the change from ASSIGNED PI to ASSIGNED PA but agreed with Larisa and Andre that there is actually no issue to be fixed.
Randy supported the aim of correct registration but also stated his concerns about the routing table and that some PI holders might not be happy to pay a fee for the sponsoring LIR.
Carlos also stated his concerns for the routing table.

Conclusion:
Five people supported the proposed approach, four people saw some advantages but also were concerned about side effects, while two people didn’t see the need to take action.

There were three opposing arguments:
- big workload compared to the gain
- increase of the routing table
- PI holders might not like to pay a fee for the sponsorship

The first opposing argument can be considered as addressed as three PI users confirmed that a clarification of that issue would be very important to them. And the RIPE NCC can support the LIRs, for example making bulk updates on route and domain objects.

The second opposing argument, could be considered that this is not directly related to the fixing of the registration. Already now all but one of the allocations in question contain more specific route advertisements. Also in the extem case that all ASSIGNED PI within the allocations would be carved out, we would talk few thousand new entries in regards to 628K total routing entries (normal growth of the routing table is around 2K per week).

The third opposing argument was addressed by Gert, stating that PI holders appreciate to pay a small fee to be sure that their resources are correctly registered.

Based on all of this I feel we have a strong enough mandate for the RIPE NCC to move forward, but some concerns about the amount of work involved. I therefore would like to ask the RIPE NCC on behalf of this working group to move forward with their plan, but to extend the proposed deadline of the end of January 2017 by a few months (the end of Q1 2017) to give LIRs a little bit more time if needed.

Cheers,
Sander
APWG co-chair

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/address-policy-wg/attachments/20161020/3c8ac80c/attachment.sig>