Hi Alex, * Alex Le Heux
But, by ignoring PI and cutting it out completely, I do feel that your proposal creates a limbo where there was none before.
Questions that will remain unanswered under the proposed policy include, but are probably not limited to:
As I understand it, if something is not explicitly mentioned in the policy, it is by default not permitted. With that in mind, I'll try to answer your points below:
- Is a PI assignment valid as long as the original criteria remain valid?
Yes, my proposal does not change or remove the relevant text that states this. See section 6.3.
- What about transfers of PI? Not allowed? Allowed?
Not allowed, because no explicit policy that allows it exists. Note that this is also the case in current policy, so my proposal upholds the status quo.
- Are sub-assignments now allowed?
Not allowed, because no explicit policy that allows it exists. Note that this is also the case in current policy, so my proposal upholds the status quo.
- Is there a requirement to keep the registration data in the RIPE DB up to date?
Yes, my proposal does not change or remove the relevant text that states this. See sections 3.0 (point 3), 4.0, and 6.3.
Even though the RIPE NCC will most likely not assign new PI in the future, these are still issues that its staff will have to deal with, and by extension, we as a community as well.
The way I see it, ASSIGNED PI is now simply a historic status, in the exact same way that, e.g., ALLOCATED PI and ASSIGNED ANYCAST is. And it remains documented as such in section 7.0 of the proposed policy. I do not quite see why ASSIGNED PI specifically needs more documentation than those other historic types of delegations. That said, if you can suggest some text to add that would resolve your concerns, I would be very happy to incorporate it into the proposal. Tore